cPanel 这次最扎眼的地方，不是又发了补丁。
而是十天内发了两次紧急安全发布。
5 月 8 日，WebPros 旗下 cPanel/WHM 发布第二次 Technical Security Release，修复 3 个漏洞：CVE-2026-29201、CVE-2026-29202、CVE-2026-29203。其中两个 CVSS 8.8，一个 4.3。
更麻烦的背景是，约十天前，cPanel 刚修过 CVE-2026-41940。那是一个 CVSS 9.8 的认证绕过漏洞，已经被用于入侵约 4.4 万台运行 cPanel/WHM 的主机，并部署 Sorry 勒索软件。
此前讨论 cPanel 风险，重点还在“约 55 万台潜在风险服务器”这个暴露面。现在补上的关键信息更具体：攻击不是理论推演，已经落到 4.4 万台；第二轮补丁也不是普通维护，更像一次事故后的代码清查。
发生了什么：三枚新漏洞，两个高危
5 月 7 日，WebPros 向客户发送预披露邮件。5 月 8 日美东时间 12:00，补丁上线。
这轮修复的 3 个漏洞如下：
| 漏洞 | CVSS | 核心风险 | 更现实的判断 |
|---|---|---|---|
| CVE-2026-29201 | 4.3 | feature 文件名校验不足，可能导致任意文件读取 | 不像直接拿 root，但可能帮攻击者摸清环境 |
| CVE-2026-29202 | 8.8 | create_user API 的 plugin 参数校验不足，可执行任意 Perl 代码 | 低门槛认证账户下风险很高 |
| CVE-2026-29203 | 8.8 | 符号链接处理不安全，可能修改任意文件权限 | 可能造成拒绝服务或权限提升 |
目前能确定被大规模利用的是前序 CVE-2026-41940，不是这 3 个新漏洞。
但管理员不能因此把 5 月 8 日补丁当成普通例行更新。十天两次 TSR，至少说明 cPanel 进入了补漏窗口：一次真实勒索攻击之后，相关代码路径被重新审视，过去没被照亮的问题开始集中浮出水面。
这才是比 CVE 编号更重要的信号。
为什么重要：共享主机里的“已认证”并不稀缺
这 3 个新漏洞都有一个限制：需要认证。
在企业自管服务器里，这个限制还算硬。账户少，权限清楚，登录来源也容易追。
放到共享主机环境里，事情就变味了。一个普通租户账号，也可能成为入口。同一台机器上挂着多个客户、多个网站、多个业务。攻击者不一定要从外面直接打穿 root，只要先拿到一个低权限账户，再找 API、文件权限、符号链接处理里的缝。
公开安全公告常说“authenticated attacker”。这句话在共享主机上没那么安慰人。
因为共享主机的商业模式，本来就是把很多互不信任的人塞进同一套系统里，再靠控制面板和权限隔离维持秩序。cPanel、Plesk、DirectAdmin 这类产品的价值也在这里：降低运维门槛，把复杂系统管理包装成按钮、API 和图形界面。
代价也在这里。
控制面板越好用，背后握着的系统能力越重。创建用户、切换权限、处理文件、修改配置，这些功能平时是效率，出错时就是攻击链材料。
“天下熙熙，皆为利来。”共享主机能便宜，靠的就是高密度复用。高密度复用省了成本，也放大了边界失守后的连锁反应。
谁最受影响：不是普通访客，是主机商和运维
普通网站访客不需要因为 cPanel 补丁立刻恐慌。
真正该加班的是两类人。
一类是共享主机服务商。风险不只在某个客户网站被黑，而在同一台服务器上的租户边界被打薄。一个账户的问题，可能拖出一串账户的麻烦。
另一类是使用 cPanel/WHM 管多站点、多客户环境的管理员。尤其是自动更新关闭、版本被固定、补丁窗口长期拖延的服务器。
现在要做的不是“看见公告，运行更新，收工”。
最低限度动作是：
- 以 root 执行
/scripts/upcp - 如果自动更新关闭或版本被固定，执行
/scripts/upcp --force - 更新后重启服务.
/scripts/restartsrv_cpsrvd - 用
/usr/local/cpanel/cpanel -V核对版本是否进入官方修复范围
更关键的是回溯。
如果服务器在 2 月下旬到 4 月 28 日之间没有及时修补 CVE-2026-41940，就不能只按“已更新”处理。它应被视为潜在失陷资产。
至少检查：
/usr/local/cpanel/logs/access_log/usr/local/cpanel/logs/login_log- 异常来源 IP
- 异常会话
- 异常登录模式
- 用户目录中的 `.sorry` 文件
发现 .sorry 文件，性质就变了。那不是漏洞管理，是事件响应。
补丁只是把门重新关上。屋里有没有人，得查。
我更在意的是：这不是一次补丁事故，是控制面板模式的老账
cPanel 不是一个小众工具。它长期存在于大量中小网站、代理商主机、托管服务商和半自动化运维场景里。
它解决的是真问题：很多人不懂 Linux、不想碰命令行、不愿自己维护邮件、DNS、数据库、权限和站点配置。控制面板把这些东西收进一个界面，生意因此跑起来。
但安全债也这么来的。
主机控制面板本质上是一个高权限翻译层：把用户的点击、API 请求、插件参数，翻译成系统级动作。只要输入校验、权限切换、文件处理里有一处松动，影响面就会超过普通 Web 应用漏洞。
这次 CVE-2026-29202 涉及 create_user API 的 plugin 参数，可执行任意 Perl 代码。CVE-2026-29203 涉及符号链接和文件权限。单看都已经够烦，放在共享主机场景里，就更像可以被拼接的零件。
目前还不能断言它们已经形成稳定链式利用。证据没到那一步。
但服务商不该等证据“漂亮”之后再行动。安全事故从来不是论文答辩。攻击者只需要一条路能跑通，运维却要证明每条路都没问题。
这就是行业最不愿说透的地方：很多主机服务并不是靠安全能力赚钱，而是靠规模、价格和省人赚钱。补丁窗口、备份策略、客户通知、日志留存，这些都是成本。平时看起来像冗余，出事时才知道是命。
PC 时代的杀毒软件、互联网早期的共享虚拟主机、云时代的托管控制台，都重复过同一件事：为了把复杂系统卖给更多人，平台会不断包一层“简单”。简单很好卖，但简单不等于风险消失。风险只是被藏到平台背后，等某个漏洞把它一次性摊开。
这次 cPanel 的问题，不必夸张成整个主机面板行业崩塌。
但它足够提醒服务商：如果你的客户隔离、自动更新、最小权限、日志审计和备份恢复都靠运气维持，那所谓“便宜好用”的控制面板，迟早会变成一张事故清单。
接下来盯什么：不是还有几个 CVE，而是官方给不给检测线索
接下来最该看的，不是 CVE 数字还会不会增加。
更有价值的是三件事：
- cPanel 是否披露更完整的影响版本
- 是否给出可执行的攻击检测线索
- 是否补充共享主机场景下的加固建议
对主机商来说，这些信息会直接决定排班、客户通知、备份恢复和是否扩大排查范围。
对使用 cPanel 的站长来说，也可以问服务商几个具体问题：服务器是否已应用 5 月 8 日 TSR？是否排查过 CVE-2026-41940 的攻击痕迹？是否扫描过 .sorry 文件？是否有可恢复的离线备份？
问这些，比问“你们安全吗”有效得多。
安全从来不是一句承诺。它是版本号、日志、备份、权限和响应时间。少一环，事故就会替你补课。