PHP2Shell：为什么 CVE-2026-109618 和 CVE-2026-109619 如此危险

2026 年 10 月 21 日，PHP 项目紧急发布 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，修复两个被评为 CVSS v4.0 9.2（Critical） 的严重漏洞：CVE-2026-109618 和 CVE-2026-109619。这两个漏洞被安全社区统称为 PHP2Shell。

真正值得警惕的地方，并不仅仅是“PHP 又出现了两个远程代码执行漏洞”。它们位于 PHP 运行时核心，攻击者可能无需账号、无需用户交互，甚至可以在业务应用自己的代码开始执行之前触发漏洞。PHP 官方因此罕见地强调：不存在完整的临时缓解方案，升级才是安全的解决办法。

两个漏洞究竟是什么

CVE-2026-109618 本质上与 PHP 处理内存耗尽（Out-of-Memory，OOM）时的异常控制流程有关。

PHP 在处理一个 HTTP 请求的过程中，会建立大量内部数据结构。如果恰好在某些结构“初始化了一部分、但还没有完全准备好”的时刻达到 PHP 的内存限制，异常处理会提前中断正常流程。然而后续清理代码可能仍然把这些不完整的数据当成正常对象继续操作，由此造成内存破坏。

PHP Foundation 表示，在 Apache mod_php 环境下，研究人员已经证明攻击者可以在默认配置、未经身份认证，并且在应用代码运行之前触发该问题，并最终实现远程代码执行；PHP-FPM 场景中也确认存在可通向 RCE 的应用级路径。

CVE-2026-109619 则属于典型的“释放后使用”（Use-After-Free）问题。

PHP 的一个 Worker 往往不会只处理一个 HTTP 请求，而是不断复用。当某次请求因为致命错误等原因异常退出时，一些 PHP 内部状态可能没有正确清理：内存已经被释放，但某些全局状态仍然保存着指向这块内存的引用。后续请求再次由同一个 Worker 处理时，就可能重新使用这块已经失效的内存，造成内存破坏，并最终被利用来执行任意代码。

换句话说，一个漏洞破坏的是“当前请求的半初始化状态”，另一个破坏的是“跨请求残留的陈旧状态”。它们的共同点是：都打中了 PHP 最核心的内存管理和错误处理机制。

为什么这两个漏洞尤其危险

第一，它们可以绕开传统的“登录后攻击”边界

很多高危 Web 漏洞至少要求攻击者首先获得普通用户账号、管理员权限，或者诱导用户执行某种操作。

PHP2Shell 不一样。

官方和多家研究机构均确认，这两个漏洞可以形成未认证远程代码执行。也就是说，只要服务器通过网络向外提供存在风险的 PHP 请求处理能力，攻击者原则上就可能直接从 HTTP 层开始攻击，不需要先突破登录系统。

这使得传统的账号安全措施——例如 MFA、强密码、管理员后台限制——无法解决问题，因为攻击目标根本不是应用的身份验证逻辑，而是身份验证逻辑下面的 PHP 引擎。

第二，漏洞位于 PHP 本身，而不是某个 WordPress 插件

这是 PHP2Shell 与大量普通 Web 漏洞最大的区别之一。

WordPress、Drupal、Joomla、Magento、Laravel 或企业自己开发的 PHP 系统只是运行在 PHP 之上。此次漏洞位于 PHP Core，因此即使应用代码完全没有明显漏洞，只要底层 PHP Runtime 存在问题，应用仍然可能暴露。

Wiz 的研究人员已经在 WordPress、Drupal 和 Joomla 等环境中演示了漏洞造成的影响。PHP 官方则直接把风险范围描述为所有处理 Web 请求的 PHP 部署，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。

这意味着：

升级 WordPress 不等于修复 PHP2Shell；升级插件也不等于修复 PHP2Shell。真正需要修复的是底层 PHP Runtime。

第三，攻击面巨大，而且大量老旧 PHP 系统仍然存在

Google Cloud 给出的受影响范围是 PHP 5.4 至 PHP 8.5.11。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 安全团队额外提供了针对 7.4、8.0、8.1 的最小源代码回移补丁，一些 Linux 发行版和长期支持厂商也可能自行回移修复，但官方仍建议迁移到受支持版本。

问题在于，PHP 长期以来被大量 CMS、共享主机、内部管理系统、旧 ERP、论坛和企业遗留应用使用。一个组织甚至可能并不知道自己还有多少 PHP 实例。

因此，这不仅是一个“严重漏洞”，还是一个典型的资产发现问题：真正困难的往往不是知道要安装哪个补丁，而是找到所有需要安装补丁的服务器、容器、镜像和嵌入式产品。

第四，成功利用后的影响远远超过“网站被黑”

远程代码执行意味着攻击者获得的不是修改某个网页字段的能力，而是在服务器上执行代码的入口。

代码首先会以 PHP/Web Server 进程拥有的操作系统权限执行。即便该账号不是 root，它通常仍然可以接触大量敏感资产，例如应用配置、数据库连接信息、API 密钥、云访问凭据、Session 数据或者内部服务地址。

由此，攻击者可以继续建立持久化后门、窃取业务数据、修改网站内容，甚至将 Web 服务器作为进入企业内部网络的跳板。CrowdStrike 特别指出，获得 Web Server 用户权限通常已经足以开展凭据收集和进一步横向移动。

此外，相关研究显示，这一类内存安全问题还可能造成服务器内存泄露。Google Cloud 和 Wiz 都提到，风险不只是执行代码，还包括敏感内存数据暴露。

因此，PHP2Shell 同时影响机密性、完整性和可用性，而不是简单的拒绝服务漏洞。

第五，补丁发布和攻击武器化之间几乎没有缓冲期

此次事件的另一个危险因素，是漏洞信息在原计划的协调披露日期之前发生泄露。

10 月 20 日，相关信息开始在公开渠道传播。PHP 安全团队随后提前发布紧急通知，并于 10 月 21 日推出安全版本。Cloudflare 表示，其针对 PHP2Shell 的 WAF 防护在正式公开披露约 9 小时前已经部署，但随后仍观察到面向客户的攻击流量，并持续根据新的攻击方式调整防护。watchTowr 随后也报告观察到了针对两个 CVE 的主动利用尝试。

截至 2026 年 10 月 22 日，需要谨慎区分两个概念：

已经确认存在现实环境中的利用尝试，并不等于已经公开确认大量服务器被成功攻陷。

Unit 42 表示已经观察到野外利用，而 Cloudflare、watchTowr 等遥测也发现了攻击活动；但公开报道对具体成功入侵案例的确认仍然有限。对于防守方而言，这种区别并不会降低修复优先级——因为攻击者显然已经开始测试和完善攻击链。

为什么一些机构宁愿暂时关闭网站

PHP2Shell 披露后，一些政府机构和在线服务选择暂时将系统下线，而不是继续保持公网可访问状态。相关新闻报道因此出现了大量网站维护、服务暂停的情况。

这看起来激进，但从风险模型上并不难理解。

一个同时具有“公网可达、无需认证、可能 RCE、影响底层 Runtime、已经出现利用活动”特征的漏洞，其最危险阶段往往就是补丁刚刚发布后的最初数小时和数天。

此时攻击者已经可以研究公开补丁差异和研究资料，而大型企业仍然需要完成资产盘点、测试、变更审批和服务重启。

如果一个关键互联网服务无法迅速完成升级，那么临时降低暴露面甚至停止公网访问，在某些场景下确实比继续裸露一个可能被直接接管的服务器风险更低。

WAF 可以挡住它吗？

WAF、反向代理、IPS 以及请求大小限制能够降低某些已知攻击路径的风险，但不应该被当作最终解决方案。

PHP 官方甚至专门列出了多种临时缓解措施，例如限制请求大小、调整内存相关配置、关闭部分 Session Upload Progress 功能等，同时明确指出这些方法只会封堵已经确认的攻击路径，不能保证整个 PHP Runtime 已经安全。

因此官方结论非常直接：

只有更新 PHP 才是完整修复。

这也是理解 PHP2Shell 危险程度的关键。如果一个漏洞可以通过简单的配置修改完全消除，风险通常还能被局部控制；而当语言维护者自己都表示“没有完整缓解措施”时，意味着依靠边界设备和配置规则只能争取时间，而不能替代补丁。

企业现在应该做什么

第一优先级不是在互联网上寻找所谓的 PoC，而是完成 PHP 资产盘点。

所有面向互联网的 PHP 服务都应该被优先检查，包括物理机、虚拟机、Kubernetes 工作负载、Docker 镜像、共享主机、旧系统以及包含 PHP Runtime 的商业产品。

如果使用 PHP 官方版本，应至少升级至 8.5.12、8.4.27、8.3.36 或 8.2.35；使用 Linux 发行版维护的软件包时，则需要确认发行版是否已经回移安全补丁，而不能仅凭版本字符串简单判断。

对于无法立即更新的公网系统，可以短期使用 WAF、限制危险请求类型、降低外网暴露、隔离服务等方式降低风险，但这些措施应当被视为临时措施。

如果系统在补丁发布以前已经长期暴露在互联网上，还应进一步检查 Web Server 和 PHP Worker 的异常行为，包括异常进程启动、PHP Worker 频繁崩溃或重启、异常 HTTP 500、可疑请求以及 Web Server 账号产生的异常外联活动。

结语

CVE-2026-109618 和 CVE-2026-109619 危险，并不是因为它们拿到了一个醒目的 9.2 分，而是因为多个高风险因素同时叠加：

漏洞位于互联网基础软件 PHP 的核心运行时；攻击可以在未认证情况下发生；部分攻击路径甚至发生在应用代码运行以前；受影响版本跨度极大；成功利用可能直接获得服务器代码执行能力；与此同时，漏洞详情提前泄露，现实攻击流量已经开始出现。

对于普通应用漏洞，安全团队通常还有时间判断“我们的业务是否真的使用了那个功能”。

面对 PHP2Shell，这个问题应该反过来问：

只要服务器正在处理 PHP Web 请求，有什么理由认为它不需要立即检查和升级？

这正是这两个漏洞最危险的地方。