PHP2Shell： 这次不是 WordPress 插件，RCE 藏在 PHP 本身

原创

JacobWang
JacobWang

NowSec

2026年11月2日 08:30
陕西

去阅读

PHP 漏洞并不少见。

WordPress 插件、CMS 模板、第三方框架、文件上传、反序列化，这些年几乎隔一段时间就会出现一个高危问题。

但 10 月 21 日披露的这两个漏洞不太一样。

问题不在 WordPress，不在 Laravel，也不在某个业务系统写错了代码。

漏洞就在 PHP 核心运行时里。

PHP 官方已经紧急发布安全更新，修复 CVE-2026-109618 和 CVE-2026-109619。两个漏洞的 CVSS v4.0 评分均为 9.2 Critical，在特定条件下都可能被未认证攻击者利用，实现远程代码执行。

官方给出的态度也非常直接：

更新是唯一完整的修复方案。

这也是为什么从 PHP 项目、英国 NCSC，到云厂商、CDN 和安全公司，都在同一天推动紧急升级。

这次到底修了什么？

两个漏洞看起来编号相邻，底层都和 PHP 的内存状态处理有关，但触发方式并不完全相同。

CVE-2026-109618 和 PHP 处理内存耗尽，也就是 OOM（Out of Memory）的方式有关。

简单理解，PHP 在处理一个 Web 请求时，如果内存分配失败，会中断当前处理流程。但在某些异常时机下，内部请求数据还没有完整初始化，后续清理逻辑却可能把这些异常状态继续当成正常数据使用。

最后的结果不是简单“PHP 进程崩了”。

研究人员已经证明，这种状态可以进一步演变成内存破坏，并最终走到远程代码执行。

CVE-2026-109619 则更像一个跨请求的“遗留状态”问题。

PHP Worker 通常不会处理完一个请求就立刻退出，而是会继续服务后面的请求。如果前一个请求因为致命错误、内存耗尽或者某些异常流程没有把内部状态清理干净，后一个请求可能继续碰到已经失效的旧内存。

一个请求留下坏状态，下一个请求把这段坏状态重新捡起来用。

从开发者视角看，这只是 PHP 引擎内部很深的一层内存管理问题。

但从攻击者视角看，只要能远程控制这个过程，结果就可能变成 RCE。

为什么这次比普通 PHP 漏洞更麻烦？

因为漏洞发生在应用代码之前。

PHP 官方确认，所有用 PHP 处理 Web 请求的常见运行方式都需要关注，包括：

PHP-FPM；
Apache mod\_php；
php-cgi；
FrankenPHP；
LiteSpeed。

其中官方认为 Apache mod\_php 风险最高，因为研究人员已经证明，在这种部署方式下，攻击可以发生在业务 PHP 代码真正开始执行之前。

这句话很关键。

很多企业遇到高危 Web 漏洞时，第一反应是：

“我们这个系统应该没有那个功能。”

或者：

“我们 WordPress 插件没装那个版本。”

但 PHP2Shell 不是这种问题。

业务代码写得安全，并不代表底下的 PHP Runtime 就安全。

Wiz 的研究甚至用 WordPress、Drupal 和 Joomla 做了 RCE 演示，但这些 CMS 只是测试对象。

漏洞本身并不属于这些 CMS。

即使上面跑的只是一个非常简单的 PHP 应用，只要底层 PHP Runtime 处于受影响状态，风险依然存在。

哪些版本需要马上处理？

PHP 官方已经发布四个正式修复版本：

PHP 8.5 → 8.5.12
PHP 8.4 → 8.4.27
PHP 8.3 → 8.3.36
PHP 8.2 → 8.2.35

只要低于对应修复版本，就应该进入升级范围。

更麻烦的是老版本。

PHP 8.1 及更早版本已经不再享受 PHP 项目的正常安全维护，但这次问题影响范围非常广，研究显示至少可以追溯到 PHP 5.x 时代。

因为漏洞严重，PHP 团队这次罕见地额外给 PHP 7.4、8.0 和 8.1 提供了最小化源码 Backport，方便没有 LTS 厂商支持的用户自行处理。

但对企业来说，这不应该成为继续留在 EOL 版本上的理由。

如果现在还在生产环境跑 PHP 5.x、7.x 或 8.0 / 8.1，这次应该顺便把“打补丁”升级成“清理历史版本”。

更新 WordPress、Laravel，没有用

这也是这次处置最容易出现的误区。

漏洞在 PHP Runtime。

所以：

升级 WordPress ≠ 修复 PHP2Shell；
升级 Laravel ≠ 修复 PHP2Shell；
更新插件 ≠ 修复 PHP2Shell；
更新 Composer 依赖 ≠ 修复 PHP2Shell。

真正要更新的是提供 Web 请求处理能力的 PHP Runtime。

这对共享主机、托管网站和一些封装产品尤其麻烦。

因为业务负责人可能只知道：

“我们用了 WordPress。”

但不知道下面到底跑的是 PHP 7.4、8.1 还是 8.3，更不知道是 FPM 还是 mod\_php。

这也是为什么这类漏洞一出现，资产台账质量马上就能被测出来。

“关掉一个配置”并不能解决问题

在补丁正式发布前，网上一度流传关闭 Session Upload Progress 就能缓解 PHP2Shell。

现在官方信息已经比较明确：

这些配置只能降低特定攻击路径的风险，不能视为完整修复。

PHP 官方确实给出了几个无法立即升级时的临时措施，例如调整内存限制、关闭 Session Upload Progress，以及 PHP 8.5 上关闭 Fatal Error Backtrace。

但官方同时强调，这些措施都只能覆盖已知利用路径。

完整修复仍然只有升级。

如果短时间确实无法升级，互联网暴露系统应该优先做访问收敛。

能暂时转内网的转内网，能通过 VPN、白名单、反向代理做限制的先限制。业务允许的情况下，甚至可以暂时下线高风险入口。

英国 NCSC 给出的建议同样很直接：如果无法升级，也无法有效实施临时缓解措施，应考虑在完成修复前将系统离线。

WAF 能不能挡？

能降低风险，但不要把它当补丁。

Cloudflare 在正式披露前已经协调部署针对 PHP2Shell 的 WAF 防护，其他厂商也在陆续推出规则。

但这类 PHP 核心内存安全漏洞并不适合把所有希望都放在请求特征匹配上。

原因很简单：

WAF 看见的是 HTTP 请求，而漏洞发生在 PHP 处理请求时的内部内存状态。

目前已知利用路径可以提取特征，不代表后续所有变体都长得一样。

WAF 适合争取升级时间，不适合代替升级。

对于有 WAF 的企业，现在更合适的做法是两条线同时推进：

一边快速上线应急检测和拦截策略，一边推进 PHP Runtime 紧急升级。

蓝队现在应该查什么？

这次处置最好不要只做版本检查。

因为技术细节已经公开，Cloudflare 也已经观察到早期利用尝试。当前公开信息还没有证明出现了大规模成功入侵，但从漏洞价值和 PHP 的部署规模来看，扫描和利用尝试很可能会迅速增加。

第一步当然是资产盘点。

重点找所有对外提供 Web 服务的 PHP，而不是只搜索 WordPress。

包括：

企业官网；
OA / CMS；
活动页和历史专题站；
外包建设的二级域名；
Laravel / ThinkPHP / Symfony 项目；
WordPress / Drupal / Joomla；
容器里的 PHP-FPM；
各类 Appliance 内置的 PHP Web 管理界面。

最后这一类尤其容易漏。

企业可能不知道某台网络设备、安全设备或者内部管理平台里面其实打包了一套 PHP。

NCSC 这次也专门提醒，不要只检查自己直接部署的 PHP，还要关注第三方产品中捆绑的 PHP Runtime。

日志上，可以先盯这几类异常

PHP2Shell 有个比较麻烦的地方：部分攻击发生在应用逻辑真正运行之前，所以业务应用日志里未必能留下很完整的信息。

Wiz 建议防守方重点关注几类信号：

异常 multipart 请求；
PHP Memory Limit / OOM 错误；
短时间集中出现 HTTP 500；
PHP Worker 异常退出或频繁重启；
异常尺寸或格式的 PHPSESSID Cookie；
PHP Worker 出现无法解释的进程或网络行为。

单独出现一个 500 当然不能说明被利用。

但如果同一来源先产生异常 multipart 请求，随后 PHP Worker 出现 OOM、500、重启，再紧接着出现异常子进程或外连，就值得按高优先级事件继续往下查。

EDR、WAF、Web Access Log、PHP Error Log 和系统进程日志最好一起关联。

只盯 WAF 是否拦截，证据是不够的。

这次还有一个很特别的背景：AI

PHP2Shell 的技术故事里还有一层值得单独说。

Wiz 在研究报告中提到，这些底层问题已经在 PHP 代码里存在很多年，有些设计甚至可以追溯到十多年前。

过去没人把它真正推进到稳定的远程代码执行，并不一定因为漏洞不存在。

而是利用链太复杂。

需要反复分析 PHP 内存状态、调整堆布局、理解不同运行方式，再针对不同环境不断调试。

Wiz 表示，前沿 AI 模型明显降低了这部分研究成本，使他们能够在数小时内开发和适配多个应用环境中的工作利用链。

AI 没有让漏洞凭空出现，它改变的是“一个复杂漏洞到底值不值得花时间利用”的门槛。

这和前面我们讨论的 ARTEX、Anthropic Cyber Mission，其实是同一条趋势。

以前“利用难度高”本身就是一道防线。

很多底层内存漏洞理论上危险，但真正要做成稳定利用，需要非常高的专业能力和大量时间。

如果 AI 把这部分时间从几周、几天压缩到几个小时，安全行业过去对“攻击复杂度”的理解也得重新算一遍。

对企业来说，现在最实际的是五件事

第一，马上盘 PHP 资产。

公网优先，但不要只查公网。容器、历史系统、外包系统、二级域名和第三方 Appliance 都要考虑。

第二，确认真正运行的版本。

不要只看项目文档。检查 PHP-FPM、Apache Module、CGI 或容器镜像里实际运行的 PHP Runtime。

第三，优先升级。

8.2、8.3、8.4、8.5 分别升级到 8.2.35、8.3.36、8.4.27、8.5.12 或厂商提供的已回补安全版本。

第四，无法升级的先收敛暴露。

WAF、VPN、IP 白名单、访问控制都可以用来争取时间，但不要把临时措施当闭环。

第五，升级前后都要做入侵回溯。

因为补丁修的是以后，不能证明补丁之前没人来过。

写在最后

PHP2Shell 最容易被写成一个很夸张的故事：

“全球 PHP 网站都危险了。”

没必要这么写。

漏洞利用仍然受到部署方式、Worker、内存布局、扩展和具体环境影响，并不是发一个请求就能稳定打穿所有 PHP 服务器。

但这也绝对不是可以等正常月度补丁窗口再处理的问题。

因为它同时具备几个很麻烦的条件：

漏洞在 PHP 核心。

不需要登录。

已经存在真实 RCE 利用链。

影响跨越不同框架和 CMS。

PHP 的实际部署量又足够大。

这次最麻烦的不是“某个网站用了有漏洞的插件”。

而是你以为安全的业务代码，可能正运行在一个需要紧急升级的 PHP 引擎上。

所以，现在最重要的问题不是：

“我们的 WordPress 有没有问题？”

而应该是：

“我们到底还有多少 PHP 在跑？跑的又是什么版本？”

PHP2Shell 最终考验的，还是企业能不能把一个底层组件漏洞，迅速映射到真实资产并完成升级。

参考资料

1. PHP Security Team：Critical remote code execution vulnerabilities, update now，2026-10-21

2. PHP Security Advisory：CVE-2026-109618 / CVE-2026-109619

3. Wiz Research：PHP2Shell: AI uncovers critical RCE vulnerabilities affecting the web

4. UK NCSC：Critical security issue affecting PHP

5. Cloudflare：Cloudflare deploys protections against php2shell vulnerability