CVE-2026-41940 — cPanel & WHM 预认证 Root 绕过（通过会话文件 CRLF 注入）

面向防御者的技术深度剖析

1. 执行摘要

cPanel 和 WHM 是共享和转售 Web 托管领域占主导地位的控制面板软件。cPanel 是面向客户的账户界面；WHM 是托管提供商和服务器所有者使用的 root 级管理界面。两者均由同一个 Perl 守护进程 cpsrvd 提供，该进程在每个服务面上监听对应的端口对（cPanel：2082/2083，WHM：2086/2087，Webmail：2095/2096）。

CVE-2026-41940 允许攻击者在没有任何凭证的情况下，在认证发生之前操纵磁盘上的会话状态，导致 cpsrvd 随后将攻击者提供的数据重新解释为合法的、完全认证的、root 特权的会话属性。结果是服务器上每个网站和账户的管理平面完全沦陷——这不只是一个租户的问题，而是一个整机、整个提供商、甚至整个行业的问题，鉴于 cPanel 的市场集中度。

2. 为什么此漏洞的重要性超越其 CVSS 分数

9.8 的 CVSS 分数相当常见，以至于可能让人麻木。三个结构性因素使得 CVE-2026-41940 在实践中异常严重：

1. 爆炸半径是整个服务器，而非单个账户。 WHM 沦陷即 root 沦陷。该服务器上的每个客户账户、每个数据库、每个 TLS 私钥、每个备份以及每个 DNS 区域都立即处于风险之中。

2. 在约两个月内，它是一个真正的零日漏洞。 KnownHost 的遥测数据将初始利用定位在 2026 年 2 月 23 日左右，远早于 4 月 28 日的补丁。任何在此期间暴露于互联网的组织都应假设沦陷是可能的，而非仅仅是理论上的，并且应进行回溯性沦陷评估，而非依赖“我们打了补丁，所以没事”。

3. 大多数受影响组织无法自行修补此漏洞。 cPanel 通常由托管提供商代表租户部署。最终客户在代码层面无法控制修复，完全依赖其提供商的补丁节奏——这正是几个大型主机商（Namecheap、KnownHost、HostPapa、InMotion）选择先发制人地在边界阻止对受影响端口的入站流量，而非等待每个租户更新的原因。

第三点值得深思。cPanel 估计控制着大约 94% 的控制面板市场。一个单一供应商会话处理代码中的逻辑缺陷，在数周内成为了事实上的全行业 root 访问漏洞。这种集中风险是一个值得内化的反复出现的主题，独立于这个特定的 CVE。

3. 架构背景

3.1 cpsrvd 与端口模型

cpsrvd 是一个长期运行的 Perl 守护进程，为所有三个 cPanel 产品面（从同一二进制文件）提供服务，关键是，使用相同的会话处理代码路径：

由于所有三个服务面共享易受攻击的会话逻辑，暴露这六个端口中的任何一个都足以进行利用——在这些服务面中并没有一个有意义的“较少暴露”的面。在良好分段的网络中，这些端口本就不应直接可达互联网；但实际上，管理便利性、混合托管安排以及防火墙漂移意味着许多端口确实暴露了。

3.2 双重会话表示

cPanel 会话以两种并行的磁盘表示持久化，可能是出于性能原因：

1. 原始会话文件（/var/cpanel/sessions/raw/<session-id>）——一种面向行的纯文本 key=value 格式，每行一个属性。
2. JSON 缓存（概念上为 /var/cpanel/sessions/cache/<session-id>）——一种结构化的 JSON 文档，正常请求路径优先读取它，因为解析开销更小。

在正常操作下，JSON 缓存是权威的，原始文件是持久性后备。漏洞的存在正是因为存在一些情况下，原始文件被重新解析并用于重新生成 JSON 缓存，而两种格式对于嵌入的换行符含义有分歧。

4. 根本原因：四个独立缺陷连锁组合

CVE-2026-41940 不是一个单一的错误。它是四个独立弱点的产物，每个单独看都是合理的孤立设计决策，但组合在一起产生了完整的认证绕过。这种“瑞士奶酪”结构对于防御者和代码审查者来说具有广泛的教育意义，远不止于这个特定产品。

4.1 第一层——由惯例而非写入路径本身强制的净化

cPanel 的会话子系统已经有一个净化例程，负责在会话值持久化之前剥离危险字符——回车、换行和 =。问题在于该例程被调用的位置：它位于更高级的包装函数（会话“创建”/“修改”API）内部，并且是调用者的责任通过那些包装器路由，而不是直接写入会话数据。

cpsrvd 内部的 HTTP 基本认证处理器——直接从 Authorization HTTP 头接受凭证的代码路径——通过一个较低级别的保存例程将提交的密码持久化到预认证会话文件中，该例程绕过了净化包装器。由于净化在写入磁盘时是可选的而非强制的，这一个调用者静默地跳过了它。

这是“在源头而非目的地验证”的教科书式失败模式：只要一个安全控制可以通过简单地调用不同函数来绕过，它最终就会被绕过，无论是由于疏忽、重构还是没有人想到针对这个特定控制审计某个代码路径。cPanel 发布的永久修复将净化调用移到了保存函数本身内部，这样任何调用者（现在或将来）都无法再跳过它。

4.2 第二层——攻击者可控输入可禁用的加密

会话写入器使用每个会话的对称密钥加密敏感字段（尤其是密码字段）。该密钥来源于嵌入在客户端提供的会话 cookie 中的一个组件。在易受攻击的代码中，如果该密钥组件在请求中不存在——完全在攻击者控制之下，因为他们选择发送什么 cookie——加密步骤被静默跳过，而不是写入被拒绝。

换句话说：有意省略或截断其会话 cookie 部分的攻击者可以导致他们自己提交的数据以未加密形式写入磁盘。其激活可以由提供输入的不可信方切换的加密并非有意义的的安全边界；它应该失败关闭（拒绝持久化或拒绝请求）而非失败开放（毫无保护地持久化）。

4.3 第三层——原始文件与 JSON 缓存之间的格式分歧

这是 CRLF 注入中“注入”的核心。原始会话文件是行分隔的：回车/换行序列终止一个 key=value 记录并开始下一个。相比之下，JSON 缓存格式将相同的字符序列表示为单个 JSON 字符串值内部的转义子字符串——语义上是惰性的，仅仅是数据。

只要一个会话只存在于 JSON 缓存中，诸如密码字段中的嵌入 CRLF 是无害的——它只是字符串中的字节。危险出现在重新解析原始文件并重新生成缓存的代码路径中。根据公开的技术分析，这发生在请求因未通过 URL 绑定的安全令牌检查而被拒绝时；负责该拒绝的处理器通过绕过缓存、逐行重新读取原始文件来重新加载会话，然后从该重新解析中重写 JSON 缓存。

在那一刻，攻击者嵌入在其提交的“密码”中的 CRLF 序列不再是惰性的字节，而是变成了记录分隔符，将本应是一个单一值的内容拆分成多个独立的 key=value 行。这些行中的每一行——包括攻击者完全控制其名称和值的行——随后被提升为重新生成的 JSON 会话缓存中的顶级条目，对于代码库的其余部分来说，与合法设置的会话属性无法区分。

一般教训：每当两个解析器可能将完全相同的字节序列解释为不同时——原始 vs. 缓存，表单编码 vs. JSON，一种转义约定 vs. 另一种——这种分歧就是一个潜在的注入原语。哪个解析器“更正确”并不重要；重要的是，不受信任的数据可以在两种表示之间跨越，而无需针对第二个解析器的语法重新验证。

4.4 第四层——一个没有加密绑定的“已认证”标志

链中的最后一环位于密码检查逻辑本身。如果一个会话已经携带了一个记录近期成功内部认证时间戳的字段，密码挑战被完全跳过——仅该字段的存在就被视为认证已成功的充分证据。一个伴生的二因素验证标志同样仅基于其存在就抑制了 2FA 挑战。

这两个字段都是为了合法的内部目的而存在的（cPanel 组件之间的单点登录交接，已经通过其他方式验证了用户的内部工具）。设计缺陷是：这两个字段都没有与任何实际认证事件进行加密绑定——它们是普通的会话属性，一旦第三层允许攻击者写入任意的会话属性，就可以简单地伪造。一个意味着“相信我，这个已经检查过了”的标志只有在不能被被信任方设置时才有意义。

4.5 复合效应

这四个弱点中没有一个单独是灾难性的：

• 缺失的净化调用是一个潜在的缺陷，直到某物以与写入时不同的方式读取受污染的数据。
• 密钥缺失时跳过加密是一个保密性问题，直到明文内容本身变得可利用。
• 双重表示格式不匹配是惰性的，直到某物从一种表示派生出另一种表示。
• 未认证的信任标志只要没有其他东西让攻击者设置它就是安全的。

连锁在一起，它们产生了完整的、未认证的、远程 root 沦陷。这正是那种范围限定在单个函数的单元测试无法捕捉到的漏洞类型，因为没有一个单独的函数是“错误的”——缺陷存在于子系统之间的交互中，而这些子系统都是各自独立推理的。

5. 概念性攻击流程

以下描述了利用的逻辑阶段，其详细程度已在供应商和行业公告中公开，不包含实际的载荷字节、编码的标头或可运行的请求序列。

从第五阶段开始，攻击者持有普通的、完全授权的 WHM API 访问权限。WHM 的合法功能集——自定义钩子、包/模板管理、PHP 处理器配置、cron 和账户管理、DNS 区域编辑——完全足以通过完全“受支持”的管理功能将此升级为交互式 root 代码执行，无需进一步漏洞。

公开报告指出，端到端链仅需要少量 HTTP 请求，并涉及围绕 Perl 在缓存重新生成期间非确定性哈希键排序的良性竞争条件——这意味着可能需要少量重试才能达到完全可靠性，这是一个具有检测价值的细节（见 §7.3）。

6. 时间线

7. 检测工程

7.1 基于文件系统的指标（信号最强）

最有力的证据存在于原始会话存储中：/var/cpanel/sessions/raw/。源自失败或非特权登录的会话绝不应该合法包含以下任何顶级字段：

• user=root
• hasroot=1
• tfa_verified=1
• successful_internal_auth_with_timestamp=<值>

...除非该会话确实通过正常登录流程完成了正确的 root 认证和 2FA 挑战。这些字段出现在一个其来源元数据显示密码尝试失败的会话上，是一个强有力的利用指标。

一个信号强度更高的指标：单个会话文件中的多行 pass=。在正常操作下，一个会话只有一个密码字段。多次出现仅由本漏洞底层的 CRLF 分割行为产生，应被视为近乎确定的沦陷指标。```bash

Sessions carrying privileged top-level fields

grep -lE '^(hasroot|tfa_verified|successful_internal_auth_with_timestamp)=1'
/var/cpanel/sessions/raw/* 2>/dev/null

Sessions with an embedded carriage return inside the password field

(indicative of CRLF-split injection rather than a single legitimate value)

grep -lP 'pass=.\r' /var/cpanel/sessions/raw/ 2>/dev/null

Sessions with more than one "pass=" line — should never legitimately occur

for f in /var/cpanel/sessions/raw/*; do n=$(grep -c '^pass=' "$f" 2>/dev/null) [ "${n:-0}" -gt 1 ] && echo "SUSPECT: $f ($n pass= lines)" done

### 7.2 访问日志关联（当会话文件未集中转发时）

如果原始会话文件保存时间不足，或未转发到集中日志系统，可以使用`cpsrvd`的访问日志作为替代。两种关联模式很有用：

**模式A——登录失败后立即出现不符合常规的Basic认证头。** 正常客户端不会在登录密码POST请求失败后，立即从同一源向任意非登录URL发送`Authorization: Basic`头。这种序列——在登录端点返回`401`后短时间内，在别处出现携带Basic认证头的请求，通过源IP和/或会话cookie关联——是异常的，值得触发告警。

**模式B——在URL中出现`cpsess`风格的令牌，而该令牌之前从未被合法颁发。** 合法的每会话安全令牌由服务器端生成，并首先出现在`Set-Cookie`/重定向响应中，然后才在后续请求URL中使用。一个在入站请求URL中出现的令牌，如果没有对应的服务器先前颁发的记录，则与正常客户端行为不一致，值得标记，特别是如果令牌不符合预期的服务器生成格式。

### 7.3 行为/重试信号

由于缓存再生受Perl的非确定性哈希键顺序影响，实际利用中观察到有时需要少量重试，才能使所需字段在再生缓存中“胜出”。短时间内一系列结构相似的请求（相同源、相同会话、相同目标URL模式，在几秒内发生），紧接着成功的管理API使用——这是一个次要的佐证信号，可与§7.1和§7.2结合使用——单独来看过于泛化，不足以触发告警，但与上述文件系统或访问日志指示符结合时，可增强置信度。

### 7.4 失陷后指标

由于WHM访问相当于root访问，请将确认的利用视为完整主机入侵调查，而非Web应用事件。检查：

- 在变更管理流程之外创建的意外WHM/root级用户帐户或经销商帐户
- 在`root`或任何托管账户的`~/.ssh/authorized_keys`中出现的新或无法识别的SSH公钥
- 无法识别的cron条目，包括系统级和每个托管账户
- 未经已知管理员配置的自定义WHM“钩子”
- PHP处理程序配置、包/模板定义或DNS区域文件的意外更改
- 作为root运行的、不属于已知cPanel/WHM服务的出站连接或进程

---

## 8. 缓解措施与事件响应手册

### 8.1 立即行动

1. **盘点**您控制或由您的提供商控制的每个cPanel/WHM/WP Squared实例。
2. **确定每个实例在披露和预披露期间**（将2026年2月23日至4月28日视为关注暴露窗口）的互联网暴露情况。
3. **修补至已修复版本：**

   | 分支 | 最低修补版本 |
   |---|---|
   | 11.110.0.x | 11.110.0.97 |
   | 11.118.0.x | 11.118.0.63 |
   | 11.126.0.x | 11.126.0.54 |
   | 11.132.0.x | 11.132.0.29 |
   | 11.134.0.x | 11.134.0.20 |
   | 11.136.0.x | 11.136.0.5 |
   | WP Squared | 11.136.1.7 |

4. **验证**已应用版本，使用`/usr/local/cpanel/cpanel -V`。
5. **修补后重启`cpsrvd`** ——未重启的守护进程可能在内存中继续运行易受攻击的代码（`/scripts/restartsrv_cpsrvd`）。
6. 如果您依赖第三方主机，**直接向提供商确认补丁状态**，而非假设已应用。
7. **禁用自动更新或固定版本的服务器**不会自动修复——这些需要明确的人工干预并应优先处理，因为它们统计上最可能仍存在漏洞。

### 8.2 短期（修补后几天内）

- 针对整个暴露窗口（不仅仅是“自我们注意到以来”）运行§7中的文件系统和基于日志的检测查询。
- 审计WHM中是否存在意外帐户、SSH密钥、cron条目和自定义钩子。
- 验证`/etc/`、`/usr/local/cpanel/`以及root的shell配置/`authorized_keys`文件的完整性，与已知良好的基线或备份对比。
- **无论是否发现失陷指标**，轮换root和经销商WHM密码、API令牌和SSH密钥——考虑到两个月的预披露利用窗口，在暴露期间主机上未发现证据并不强力证明没有失陷。
- 修补后清除会话状态（`/var/cpanel/sessions/raw/`和JSON缓存目录），以防止残留的伪造会话被重放。

### 8.3 长期加固

- 限制对cPanel/WHM/Webmail端口（2082、2083、2086、2087、2095、2096）的入站访问，仅允许已知管理IP范围通过防火墙白名单。在正常操作条件下，这些管理平面端口不应广泛对互联网可达。
- 将`cpsrvd`访问日志——以及理想情况下会话写入事件——转发到中央保留的SIEM，因为主机上会话文件是短暂的，如果在分析期间未及时保存，很容易丢失。
- 建立预期的WHM帐户、SSH密钥和cron作业的基线清单，并监控漂移。
- 将cPanel/WHM版本和补丁节奏作为首要资产管理指标进行跟踪，特别是对于任何自管理（非外包）实例。

### 8.4 如果确认失陷

- **不要尝试对root失陷的主机进行现场修复。** 一旦获得root权限，攻击者可以修改任何内容，包括您用于调查的工具。将现场“清理”视为不可靠。
- **从已知干净、已修补的镜像重建**，而不是修补并继续运行可能失陷的系统。
- **轮换所有管理凭据**，不仅限于直接涉及的凭据。
- **替换所有SSH密钥**，包括属于托管客户帐户的密钥，因为root级攻击者可能已收集或植入任何密钥。
- **假设该主机上托管的所有客户数据已暴露**，并履行适用的违规通知义务。
- **调查横向移动**进入相邻内部网络段，因为失陷的托管基础设施通常是进入企业环境的跳板（例如，通过凭据、SSH信任关系或别处重复使用的共享秘密）。

---

## 9. 常见问题解答

**这能像蠕虫一样传播/适合大规模自动利用吗？**
底层攻击链完全无需认证，且涉及少量固定的HTTP请求，这就是为什么CISA将其升级为KEV状态，以及引用此CVE的大规模扫描工具已公开出现。将任何未修补、可互联网访问的实例视为面临机会主义、自动利用的主动风险，而不仅仅是有针对性的攻击。

**双因素认证能防御此漏洞吗？**
不能。注入直接伪造了“2FA已验证”的会话标志，因此2FA挑战根本不会出现。2FA对此特定漏洞不提供任何缓解。

**我的WAF能捕获这个吗？**
只有在WAF既能够规范化/检查`Authorization: Basic`负载中嵌入的CRLF序列，又能单独检查会话cookie中与加密跳过条件相关的畸形/截断模式时，才能捕获。通用WAF规则集通常未能检测到此问题的预披露利用。无论WAF状态如何，修补仍是强制性的。

**这会影响cPanel DNSOnly部署吗？**
是的，根据厂商公告，DNSOnly安装也在范围内。

**较旧的、不受支持的（11.40之前）cPanel版本受影响吗？**
不——根据公开分析，易受攻击的代码路径在11.40分支之前的版本中不存在，因为不受支持的旧版本早于相关的会话处理实现。

**如果无法立即修补，是否有变通方案？**
除了修补之外，没有可完全关闭漏洞的功能性变通方案。唯一有效的临时缓解措施是在网络边界阻止对受影响端口（2082/2083、2086/2087、2095/2096）的入站访问，或完全停止`cpsrvd`/`cpdavd`服务，但这都会牺牲合法访问。

---

## 10. 软件与安全工程的更广泛教训

独立于cPanel，此漏洞对于任何在别处审查认证和会话处理代码的人来说，是一个有用的案例研究：

1. **在持久化点进行清理，而非由调用方自行决定。** 任何可以通过在同一子系统中调用不同函数来绕过的安全控制最终都会被绕过——无论是发现漏洞的攻击者，还是不知道其存在的未来工程师。
2. **安全控制在输入缺失或畸形时必须失败关闭，绝不可失败开放。** 如果密码操作依赖于客户端提供的材料，缺少该材料应中止操作，而不是静默跳过本应提供的保护。
3. **同一数据的每个双重表示都可能是潜在的走私原语。** 无论系统在何处维护同一状态的两种序列化（原始与缓存、表单编码与JSON、转义与未转义），并在之后从一种派生出另一种，请专门审计该重新派生路径，查找不受信任数据可未经过滤跨越边界的情况。
4. **信任标志必须密码学绑定到其断言的事件，而不仅仅是存在。** 意味着“认证已成功”的会话属性只有在攻击者无法独立设置该属性时才安全——通过签名、MAC或等效绑定到实际认证事件，而非未经认证的存储。
5. **作为未经认证请求的结果写入磁盘的任何数据都必须视为攻击者可控**，包括仅由其他看似无关的代码路径读回的数据。此漏洞的危险不在于写入数据的代码，而在于一个完全不同的、后来的代码路径，该路径在不同的解析规则下重新解释数据。

---

## 11. 参考资料

- cPanel安全公告——*cPanel与WHM登录认证的关键漏洞*，2026年4月28日——`docs.cpanel.net/release-notes/release-notes`
- watchTowr实验室——原始根因分析和概念验证，Sina Kheirkhah，2026年4月29日——`labs.watchtowr.com`
- Rapid7——CVE-2026-41940新兴威胁报告——`rapid7.com`
- Arctic Wolf——CVE-2026-41940威胁摘要——`arcticwolf.com`
- Hadrian——*CVE-2026-41940：cPanel中的关键认证绕过*——`hadrian.io`
- Picus Security——*CVE-2026-41940解析：影响150万服务器的cPanel与WHM认证绕过*——`picussecurity.com`
- CISA已知被利用漏洞（KEV）目录中CVE-2026-41940条目——`cisa.gov`
- BleepingComputer、The Hacker News、CyberScoop——关于披露及野利用的同期报道
- WP Squared更新日志——`docs.wpsquared.com/changelogs`
- KnownHost社区咨询文档，记录疑似披露前利用情况