PHP 爆出两个 RCE 高危漏洞——相关信息与响应

漏洞简介

2026年10月21日，PHP紧急安全公告，CVE-2026-109618、CVE-2026-109619 两个远程命令执行漏洞爆出。

二者 CVSS 评分等级均为 9.2，均无需认证要求，均发生在业务代码执行之前，均位于 PHP 核心运行时——这意味着即便项目本身不存在任何漏洞，也会受到此漏洞的影响。

二者被社区并称为“PHP2Shell”。

漏洞档案

属性	CVE-2026-109618	CVE-2026-109619
CVSS v4.0	9.2（Critical）	9.2（Critical）
漏洞类型	RCE via OOM corruption（内存耗尽处理中的内存损坏）	RCE via stale global state（全局状态残留导致释放后使用）
GHSA编号	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp
认证要求	未经身份验证（Pre-Auth）	未经身份验证（Pre-Auth）
触发位置	业务代码执行之前	业务代码执行之前

CVE-2026-109618：内存耗尽（OOM）路径上的初始化不完整

PHP 在处理内存耗尽时，通过 longjmp() 直接跳出当前执行上下文。问题在于，在某些时间窗口内，请求相关的内部数据已经可以被访问，但尚未完成初始化。如果此时发生内存分配失败，longjmp() 会跳过正常的初始化收尾流程，请求清理程序随后将这些未初始化的无效数据当作有效数据处理，最终导致内存破坏和代码执行。

简而言之：内存耗尽时，PHP 可能在请求内部数据尚未初始化完整前中断处理。后续清理流程若把这些无效数据当成有效数据处理，就可能触发漏洞。

CVE-2026-109619：工作进程复用中的“陈旧状态残留”

PHP 工作进程（worker）会被复用来处理多个请求。部分内部全局状态（如错误回溯、会话、对象、扩展状态）保留在工作进程中，但指向的是单次请求所持有的内存。正常情况下，请求结束前这些引用应被正确重置。漏洞在于：当致命错误、解析失败、超时或清理阶段的诊断信息写入后，状态可能在底层内存已经释放后仍然残留。同一 worker 处理下一个请求时，如果在正常初始化重置之前，某个操作先读取了这些旧引用，就会触发释放后使用（Use-After-Free）。

简而言之：某个请求使用的内部状态可能在其占用的内存释放后仍被保留下来。同一个 worker 处理后续请求时，如果在正常初始化并重置状态前使用了这份旧状态，就可能触发漏洞。

影响范围：从 PHP 5.4 起

该漏洞影响所有处理网页请求的PHP环境，包括 PHP-FPM、Apache mod_php（最高风险部署）、php-cgi、FrankenPHP 及LiteSpeed 等。

分支	修复版本
PHP 8.5.x	8.5.12
PHP 8.4.x	8.4.27
PHP 8.3.x	8.3.36
PHP 8.2.x	8.2.35
PHP 8.1 / 8.0 / 7.x / 5.4–5.6	已 EOL

对于 EOL 分支版本，官方仅提供了 PHP 7.4、8.0、8.1 的最小源码回移补丁，最佳方法仍是升级到官方维护周期内的版本。

Cisco Talos 基于开源情报估计，约50%的PHP系统将不会收到补丁，主要原因是大量部署仍运行在 EOL 分支上。

PHP 8.1 and older are end of life (EOL), and PHP 8.2 security support ends Dec. 31, 2026. Talos’ initial estimates based on open-source intelligence show a significant corpus of PHP systems that will not receive a patch (~50%). If your organization is running PHP 8.1 or older, Talos very strongly advises immediate update to PHP 8.2 or later. There is no patch for PHP 8.1 or older.

——Two critical RCEs in PHP core

解决漏洞：补丁优先

应当迅速将 PHP 升级至官方补丁修复版本。

这里贴出 OpenLite Speed 与 LSPHP 的升级方法（如果使用的是 LiteSpeed Enterprise，可以使用 lsup.sh，Changelog | LiteSpeed Web Server | LiteSpeed Documentation）：

如果当时使用的是 apt 等包管理器安装的 OLS（这也正是我的情况），也需要通过这些包管理器进行升级。

对于 Debian/Ubuntu 系统：

# 更新软件包列表
apt-get update

# 升级 OpenLiteSpeed 自身（如果可用）
apt-get install --only-upgrade openlitespeed -y

# 升级所有 lsphp 包（这是修复PHP2Shell的关键）
apt-get install --only-upgrade 'lsphp*' -y

对于 CentOS/AlmaLinux/Rocky Linux 系统：

# 升级 OpenLiteSpeed 自身
yum update openlitespeed -y

# 升级所有 lsphp 包
yum update 'lsphp*' -y

缓解漏洞：实为下策

PHP官方在公告中明确：没有能够完整替代补丁的配置缓解方案。以下措施仅用于降低特定攻击路径的暴露，不能替代升级。

官方建议 memory_limit=-1（通过 php_admin_value 设置，确保应用无法覆盖），以消除可控的内存耗尽失败；同时设置较低的 post_max_size（无上传需求时8M，有上传时32M），并在 Web 服务器/反向代理层限制解码后请求体大小、输入字段数、multipart part 数、头部数量、嵌套深度，包括没有可用 Content-Length 的请求。注意：不要用 RLIMIT_AS / RLIMIT_DATA 作为替代，因为这些限制本身可能触发漏洞路径。

或者也可以通过 WAF 等缓解攻击。例如 CloudFlare 早就在漏洞发布前对包括免费版在内的所有 WAF 配置了漏洞缓解规则。不过必须强调的是，这些CDN虽然可以缓解正面攻击，但 WAF 仍有绕过风险，最佳解决方案仍是迅速更新至最新版本。