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

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

1. 执行摘要

字段	值
CVE ID	CVE-2026-41940
CVSS v3.1	9.8（严重）— 网络 / 低复杂度 / 无需权限 / 无需用户交互
漏洞类别	预认证 CRLF 注入 → 会话文件投毒 → 认证绕过
CWE	CWE-93（CRLF 序列未适当中和），更接近 CWE-117（日志/文件的输出未适当中和），因为注入的 CRLF 落在磁盘上的会话文件中，而非 HTTP 响应头
受影响产品	cPanel、WHM（WebHost Manager）、WP Squared
影响	未认证、远程获取 WHM 中完全特权的 root 管理会话
披露日期	2026 年 4 月 28 日（cPanel 安全公告）
CVE 分配	2026 年 4 月 29 日
野外利用	据托管提供商 KnownHost 称，最早于 2026 年 2 月 23 日观察到利用 — 比补丁发布早约两个月
CISA KEV	披露后不久添加
估计暴露范围	约 150 万个面向互联网的 cPanel 实例（Rapid7 引用的 Shodan 遥测数据）；cPanel 估计占据 Web 控制面板市场约 94% 的份额（W3Techs）
临时缓解措施	无 — 打补丁是唯一完整的补救措施

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 在实践中异常严重：

爆炸半径是整个服务器，而非单个账户。 WHM 沦陷即 root 沦陷。该服务器上的每个客户账户、每个数据库、每个 TLS 私钥、每个备份以及每个 DNS 区域都立即处于风险之中。
在约两个月内，它是一个真正的零日漏洞。 KnownHost 的遥测数据将初始利用定位在 2026 年 2 月 23 日左右，远早于 4 月 28 日的补丁。任何在此期间暴露于互联网的组织都应假设沦陷是可能的，而非仅仅是理论上的，并且应进行回溯性沦陷评估，而非依赖“我们打了补丁，所以没事”。
大多数受影响组织无法自行修补此漏洞。 cPanel 通常由托管提供商代表租户部署。最终客户在代码层面无法控制修复，完全依赖其提供商的补丁节奏——这正是几个大型主机商（Namecheap、KnownHost、HostPapa、InMotion）选择先发制人地在边界阻止对受影响端口的入站流量，而非等待每个租户更新的原因。

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

3. 架构背景

3.1 cpsrvd 与端口模型

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

端口对	服务面	受众
2082 / 2083	cPanel	最终客户（按账户）
2086 / 2087	WHM	Root/转售管理员
2095 / 2096	Webmail	电子邮件用户

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

3.2 双重会话表示

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

原始会话文件（/var/cpanel/sessions/raw/<session-id>）——一种面向行的纯文本 key=value 格式，每行一个属性。
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. 概念性攻击流程

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

阶段	攻击者完成什么	利用的底层缺陷
1. 创建一个预认证会话	通过一次普通的（故意失败的）登录尝试触发磁盘上会话文件的创建——不需要任何有效凭证。	会话文件在认证成功之前就创建，并且被信任为后续合法登录的基础。
2. 将带有 CRLF 的数据走私到原始会话文件中	通过 HTTP Basic-auth 代码路径提交攻击者控制的数据，使用避免加密步骤的请求框架，使数据以未净化和未加密的形式落在磁盘上。	第一层和第二层（缺失的净化调用；可跳过的加密）。
3. 强制重新解析原始文件	触发特定的拒绝代码路径，该路径导致 `cpsrvd` 绕过 JSON 缓存并逐行重新读取原始会话文件，然后从该重新解析重新生成缓存。	第三层（原始表示与缓存表示之间的格式分歧）。
4. 特权提升完成	重新生成的 JSON 缓存现在包含攻击者选择的顶级字段，标志该会话属于 `root`，具有 root 特权，已通过 2FA，并且具有一个近期的成功认证时间戳——加上一个攻击者选择的安全令牌。	第三阶段的直接后果。
5. 使用伪造的会话	任何后续呈现此会话和攻击者选择的安全令牌的请求都会被 `cpsrvd` 视为完全认证的 root 管理员：近期时间戳字段抑制密码提示，已验证标志抑制 2FA，而令牌满足每次请求的 CSRF 风格检查。	第四层（未绑定的信任标志），加上来自第四阶段的伪造。

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

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

6. 时间线

日期	事件
~2026 年 2 月 23 日	据托管提供商 KnownHost 的遥测数据和后续开源报告，最早怀疑的野外利用。被响应者视为真正的披露前零日漏洞。
2026 年 4 月 28 日	cPanel 在所有受支持分支以及 WP Squared 上发布了紧急安全更新。供应商发布说明仅将其描述为“会话加载和保存的问题”，最初未详细说明严重性。
2026 年 4 月 29 日	CVE-2026-41940 正式分配；CVSS 9.8 发布。watchTowr Labs（Sina Kheirkhah）发布了第一个公开的技术根本原因分析和概念验证。
2026 年 4 月底至 5 月初	多个主要托管提供商（Namecheap、KnownHost、HostPapa、InMotion 等）先发制人地在网络边缘阻止对端口 2083/2087（及相关端口）的入站流量，以在单个租户修复之前保护未打补丁的租户。
~2026 年 4 月 29–30 日	CISA 将 CVE-2026-41940 添加到已知被利用漏洞（KEV）目录。独立供应商分析（Rapid7、Arctic Wolf、Hadrian）在 24–48 小时内跟进。
2026 年 5 月 1 日	额外的独立面向防御者的说明（例如 Picus Security）发布，整合了检测和缓解指南。
持续进行中	引用此 CVE 的公开可用扫描和利用工具（包括批量扫描器）出现在公共代码托管平台上，表明该利用已从有针对性的零日使用转变为商品化/机会性扫描。

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 行为/重试信号

最受欢迎

CVE-2026-41940-analysis