2026 年 10 月 21 日 13:40 UTC，PHP 项目发布 8.5.12、8.4.27、8.3.36、8.2.35 四个版本，一次性修复两个 CVSS 4.0 评分 9.2 的严重漏洞。它们被统称为 PHP2Shell——未经身份验证的远程攻击者，只要构造一个特制 HTTP 请求，就可能拿下服务器。
这是 PHP 官方近两年最重的一次安全事件。技术细节与 PoC 已广泛传播，多国政府机构与企业网站一度直接关站避险。本文先把事情讲清楚：漏洞是什么、为什么这么严重、以及它是怎么拖了两年的。
一、事件时间线
| 时间 | 发生了什么 |
|---|---|
| 2024 年 | PHP 首次接受外部安全审计（OSTIF 资助、Quarkslab 执行）。修复过程中，核心开发者发现了 OOM 问题的最初迹象，但当时没找到可用的攻击路径。 |
| 2024—2026 | 修复方案反复推翻重来：每个方案都带来兼容性破坏、新 DoS 风险，或需要大量第三方扩展配合，决策多次停滞。 |
| 2026 年 5 月 | PHP 基金会成立 Ecosystem Security Team，与安全团队并行做 triage、协作与加固。 |
| 2026 年 7 / 9 月 | Alexandre Daubois、Daniel Scherzer 先后加入，分别负责漏洞 triage 与加固工作。 |
| 2026 年 10 月 21 日 | 四个修复版本同时发布，安全公告同步公开完整技术细节。 |
| 2026 年 10 月 22 日 | CNVD 收录为 CNVD-2026-41674 / CNVD-2026-41675，评级「高危」；ENISA、CERT-EU、Europol EC3 及多国 CERT 联合发布声明。荷兰、芬兰、日本等地部分机构与企业选择临时关站。 |
二、漏洞一：CVE-2026-109618 —— 内存耗尽时的「半初始化」数据
官方描述很简洁：out-of-memory handling can lead to memory corruption and the execution of malicious code。翻译成人话：
当一个请求触碰到 memory_limit 上限时，PHP 会在内部数据只初始化了一半的状态下被强行中断。请求清理阶段随后可能把这批无效数据当成有效数据继续使用，从而破坏内存结构。
关键点在于：攻击者可以自己制造这个触发条件——发一个足够大的请求，让 PHP 恰好在错误的时刻触顶。剩下的就是内存破坏的利用问题。在 Apache + mod_php 下，未经认证的请求可以在任何应用代码运行之前就触发这条路径，研究者已在默认配置下演示了完整的远程代码执行；PHP-FPM 下也确认了通过应用层代码路径可达成 RCE。
三、漏洞二：CVE-2026-109619 —— 跨请求的陈旧状态
这一条更隐蔽：invalid internal states may persist between requests。
如果一次致命错误发生在错误的时机，PHP 的内部状态会指向属于上一个请求、但已经释放的内存。后续由同一个 worker 处理的请求，可能在正常初始化重置它之前，先用到这份陈旧状态——典型的 use-after-free。研究者确认了 worker 崩溃，并在真实应用上完成了远程代码执行演示。
把它理解成「同一个房间里，上一位客人走了却把东西留在那，下一位客人进来先拿到的是他的东西」，就不难明白为什么它比第一个漏洞更难防守：错误状态能跨请求存活。
四、为什么 mod_php 风险最高
官方明确表示「在 Apache + mod_php 下风险最高」，原因是攻击链短了一整步：
- mod_php：请求进入 PHP 时，内存管理与错误处理早已就位，恶意请求可在应用代码执行前触发 —— 你的业务代码一行都跑不到。
- PHP-FPM：需要经过应用层代码路径才能到达受影响位置，攻击面相对收敛。
- php-cgi / FrankenPHP / LiteSpeed：同样在受影响范围内，不可因为「不是 mod_php」而放心。
五、影响版本
| 版本线 | 受影响 | 修复版本 |
|---|---|---|
| 8.5.x | < 8.5.12 | 8.5.12 |
| 8.4.x | < 8.4.27 | 8.4.27 |
| 8.3.x | < 8.3.36 | 8.3.36 |
| 8.2.x | < 8.2.35 | 8.2.35 |
| 8.1 及更早 | 全部受影响 | 官方不再更新（部分发行版 / LTS 厂商提供回移植补丁） |
由于漏洞位于解释器内核，受影响的远不止「用 PHP 写网站」的场景：Magento、WordPress、Drupal、Joomla、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS、OpenCart 等主流 CMS 与框架都建立在受影响的运行时之上。据公开数据，已确认暴露的受影响服务器超过百万台，其中相当一部分使用的还是已结束官方支持的版本。
六、它为什么拖了两年
这是本次事件里最值得复盘的部分。PHP 基金会自己的解释是：「这是结构性失败」——安全团队的决策流程，加上真正懂引擎的少数核心开发者精力分散，导致修复工作数月内反复停滞重启。
技术上的原因是真实的：修复必须同时满足「不破坏兼容性」「不引入新的拒绝服务」「不让大量第三方扩展无法编译」这三件事，而每一个候选方案都至少违反一条。2026 年 5 月成立专门团队、7 月和 9 月补人、引入 AI 工具做扫描与验证之后，流程才真正跑起来。
另一个信号是欧盟《网络韧性法案》（EU 2024/2847）：自 2026 年 9 月 11 日起，硬件与软件制造商必须通过 Single Reporting 平台报告被积极利用的漏洞。这会持续倒逼上游把安全响应变成硬性流程，而不是靠几个人的个人推动。
七、现在该做什么
完整解决方案只有一个：升级到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。升级后要重启 PHP 服务与常驻进程，容器需要重新构建部署。
如果暂时无法升级，官方同时给出了一组临时缓解措施——它们只降低特定攻击路径，不等于安全，细节见《不能马上升级？官方给的临时缓解措施与它们的边界》一文。
还有一件事必须记住：更新不能修复已经发生的入侵。如果你的站点在漏洞窗口期内对外暴露过，升级之后仍需做一次完整的入侵排查。
参考来源
- PHP 官方安全公告：php.net/archive/2026.php
- PHP 基金会复盘：Today's PHP Security Release
- ENISA / CERT-EU 联合声明：enisa.europa.eu
- 国家互联网应急中心安全公告：CNVD-2026-41674 / CNVD-2026-41675