安全
LiteSpeed 修补了共享主机上的一次 root 越权。但它没有给这个漏洞编号
LiteSpeed Web Server Enterprise 6.3.7 悄悄修复了一个可让单个托管账户拿到共享服务器 root 权限的漏洞,被击穿的正是整个共享主机模式所依赖的隔离。没有 CVE,没有严重性评分,也没有关于是否遭利用的说明——出面示警的是 cPanel。
MAI
9 月 11 日,LiteSpeed Technologies 发布了 LiteSpeed Web Server Enterprise 6.3.7 版。其发布日志里有三条标注为 SECURITY 的条目,夹在一项新的后量子密码选项和一处关于服务器如何处理 Node.js 进程的修复之间。三天后,cPanel 发布安全公告,说明了其中至少一条到底是为什么而来:这是 Web 服务器中的一个权限提升漏洞,低权限的托管账户可以借此突破自己的账户边界,在该主机上拿到 root。
到现在它仍然没有 CVE 编号,没有严重性评分,两家公司也都没有说明它是否已被用来攻击过谁。
受影响范围
| 产品 | LiteSpeed Web Server Enterprise |
| 受影响版本 | 6.3.7 之前的所有版本 |
| 修复版本 | 6.3.7(2026 年 9 月 11 日发布) |
| CVE | 截至 9 月 15 日尚未分配 |
| 严重性评分 | 未公布 |
| 是否遭利用 | 两家公司均未说明 |
cPanel 的公告把后果写得很直白:在该服务器上持有一个普通托管账户的攻击者,可以利用这个漏洞
访问或篡改同一服务器上托管的其他网站以及服务器本身。
该漏洞还能绕过 CageFS,也就是 CloudLinux 按账户隔离文件系统的机制。大多数共享主机商正是靠它把一个客户挡在另一个客户的文件之外。两家公司都没有解释绕过是如何发生的,而变更日志里的那几条——增强 lscgid 请求认证与校验、加强对内部重定向 URL 的验证、阻止从 .htaccess 设置内部专用环境变量——也没有指明是哪一条堵住了这个口子。
为什么这类漏洞比评分显示的更糟
根据 W3Techs 2026 年 9 月的统计,在能够识别出 Web 服务器的全部网站中,14.6% 使用 LiteSpeed。这个份额并非均匀分布。LiteSpeed Enterprise 是可直接替换 Apache 的商业产品,主要卖给主机托管公司,其重心恰好就是这个漏洞最危险的环境:一台物理服务器承载数百到数千个彼此无关的客户,而把它们隔开的只有软件。
在这种架构里,账户边界就是安全模型的全部。跨过这条边界的漏洞,危害的不是一个站点,而是这台机器上的每一个站点,以及放在上面的凭据、数据库和备份。而且入场费很低。攻击者不需要钓鱼管理员,也不需要去找暴露在外的管理端口,只要在一家存在漏洞的主机商那里买一个托管账户——花几美元,这一步本身不涉及任何攻击。
这也是今年第三条经由 cPanel 服务器上的 LiteSpeed 组件通往 root 的路径。5 月的 CVE-2026-48172 和 6 月的 CVE-2026-54420 针对的都是 LiteSpeed 的 cPanel 插件,两者都曾在野遭到利用,也都被收入 CISA 的已知被利用漏洞(KEV)目录。9 月这个漏洞则是第一次出现在 Web 服务器本体,而不是控制面板周边的粘合层。这意味着"卸载或限制插件"这种较小的缓解手段不再适用——存在漏洞的组件,就是正在对外提供页面的那个程序。
真正的问题在于披露方式
值得写的不是漏洞本身,它的细节两家公司之外没人见过。值得写的是它以何种方式进入公共视野。
LiteSpeed 维护着一个相当活跃的安全博客。8 月 27 日,它在那里发布了旗下 WordPress 缓存插件的两个跨站脚本问题,各自都带 CVE;9 月 2 日又发布了 Patchstack 报告的一个服务端请求伪造问题。这些问题真实存在,但都不严重。而旗舰商业 Web 服务器上一个跨越租户边界拿到 root 的漏洞,却什么都没有:没有博客文章,没有编号,也没有自己的安全公告。管理员之所以收到警告,是因为 cPanel 决定写一份。
没有 CVE,这个漏洞对业界为应对此类情况而建立的整套机制来说就等于不存在。漏洞扫描器以编号为索引,补丁管理系统、合规报告、保险公司的问卷以及 CISA 的 KEV 目录同样如此。今天一家主机商去做资产盘点,在任何地方都不会看到这一条,因为根本没有可列的对象。前两个 LiteSpeed 漏洞被这套机制捕捉到,也都是在编号之后,而且两次都已经是在野利用开始之后。
对是否遭利用保持沉默,同样不等于没有被利用。这套组件此前的两个漏洞,最终都被证实正在被实际攻击使用。在一个部署广泛的托管平台上,能用一个买来的账户拿到 root 的漏洞,对那些大规模扫描此类目标的人来说近乎理想。而静默补丁与 cPanel 公告之间那三天,是修复已经公开、警告却尚未存在的三天。
应当怎么做
如果你在运行 LiteSpeed Enterprise,请升级到 6.3.7。LiteSpeed 记录在案的升级方式是 /usr/local/lsws/admin/misc/lsup.sh -f -v 6.3.7。另外,6.4.0 RC2 已于 9 月 14 日发布,但在生产环境的托管集群上,该去拿的修复不是候选发布版。
如果你是用户而不是运营方,坦率地说,你没有办法自行核实,因此直接去问是合理的。一家能告诉你自己用的 LiteSpeed 版本以及何时打的补丁的主机商,是一家在留意这些事的主机商。升级之后,运营方应把补丁当作起点而不是终点,检查相关服务器上的 CGI 活动与日志记录——目前公开的信息都不足以说明这个漏洞从何时起可被利用,也不足以说明它是否已被实际使用。
Sources: LiteSpeed Web Server release log · The Hacker News: LiteSpeed Enterprise Flaw Could Let One Hosting Account Gain Root Access on a Shared Server · LowEndTalk: 14 Sep 2026 — LiteSpeed Enterprise security advisory (URGENT) · The Hacker News: CISA Flags LiteSpeed cPanel Plugin Flaw Exploited for Root Privilege Escalation · Security Affairs: CISA adds Cisco Catalyst and LiteSpeed cPanel plugin flaws to its KEV catalog · Cyber Security Agency of Singapore: Critical Vulnerability in LiteSpeed User-End cPanel Plugin · LiteSpeed blog · W3Techs: Usage statistics of LiteSpeed