AI 先找到 PHP 致命漏洞：真正跟不上的，是整个互联网的修复速度

2026 年 10 月 20 日，PHP 项目发出一则不寻常的预告：第二天将发布紧急安全版本，修复两项 CVSS 9.2 的严重漏洞。公告没有给出技术细节，只要求所有 PHP 用户提前准备升级。

不到一天后，答案揭晓。CVE-2026-109618 与 CVE-2026-109619 被统一称为 PHP2Shell。它们不在某个 WordPress 插件里，也不属于某个 CMS 的登录接口，而在 PHP 运行时本身。研究团队已经在受控环境中证明，受影响部署可能出现未认证远程代码执行或进程内存泄露。PHP 随即发布 8.5.12、8.4.27、8.3.36 与 8.2.35，官方措辞没有留下太多解释空间：临时缓解只能降低部分路径的暴露，升级才是完整解决办法。

如果只看严重度，这是一篇“马上打补丁”的安全快讯。但 PHP2Shell 更值得写的地方，是它把 AI 安全研究最乐观与最棘手的一面同时摆在了桌上。

AI 确实帮助防守方提前找到了问题。可当漏洞进入修复、回移、云平台通知、托管商部署、企业资产盘点和服务重启阶段，速度突然又回到了现实世界。模型可以连续工作，互联网却不是一个可以一次性更新的软件包。

PHP2Shell 留下的问题是：当漏洞发现被 AI 加速，修复体系能不能跟上？

图 1：PHP2Shell 协调时间线。根据 OpenAI、Wiz、PHP 与 Cloudflare 的公开资料整理。

先把角色说清楚：AI 找到了什么，谁完成了修复

这起事件很容易被写成“AI 发现并修复了 PHP”。事实没有这么简单。

OpenAI 的披露写得很明确：Calif 在 Patch the Planet 项目中使用 GPT-5.6 Sol 识别出一项关键缺陷；Wiz 则独立发现并报告了两项漏洞。Wiz 的研究还使用了自家的研究系统以及其他前沿模型，完成跨应用验证。AI 在代码理解、假设生成、重复调试和适配不同目标上显著降低了研究成本。

但修复不是模型自动合并的一次提交。PHP 维护者主导了漏洞确认、根因修复和版本发布；研究团队协助验证；Cloudflare、Akamai、Imperva 等安全与基础设施提供商准备防护；Linux 发行版、LTS 厂商、托管商和控制面板供应商还要处理自己的回移与发布节奏。

OpenAI 表示，这一协调过程持续了约两个月。Wiz 公布的时间线显示，其团队在 8 月中下旬完成发现、验证并向 PHP 安全团队报告；PHP 在 10 月 21 日公开修复版本。模型帮助缩短了“找到并证明问题”的时间，但后面的工作依然需要大量人类组织协作。

更准确的说法是：AI 把原本极难完成的漏洞研究推进到了可操作阶段，维护者和基础设施生态再把研究变成可部署的保护。

两个漏洞危险在哪里

PHP 官方把两项漏洞概括为两类错误处理后的内存状态破坏。

第一类发生在内存耗尽错误之后。PHP 需要迅速退出当前执行上下文，但部分内部数据可能只初始化了一半。后续清理流程如果把这些无效数据当成正常对象使用，就可能造成内存破坏，严重时发展成代码执行。

第二类发生在致命错误之后。某些本应只属于当前请求的状态，在请求结束、相关内存已释放后，仍被全局状态引用。处理同一 worker 上后续请求时，PHP 可能再次使用这些已经失效的指针，引发跨请求的内存泄露或破坏。

图 2：防守性原理示意。图中刻意省略触发条件、请求结构和利用链。

这两段描述已经足以解释风险，不需要把攻击步骤重演一遍。它们共同暴露的是一个老问题：当底层运行时通过非局部跳转迅速离开错误现场时，部分生命周期管理可能被绕开。平时难以走到的边界状态，在攻击者可以反复控制输入和资源压力时，就可能变成稳定入口。

Wiz 在 WordPress、Drupal 和 Joomla 的受控环境中演示了未认证远程代码执行，也展示了与具体应用无关的进程内存泄露。但这些 CMS 只是代表性目标。漏洞在 PHP 内核里，简单 PHP 页面同样运行在受影响的解释器之上。反过来说，也不能把“运行 PHP”直接等同于“必然可利用”：版本、部署方式、模块、worker 模型和配置都会影响具体路径。

这里最重要的边界是：PHP 的广泛部署说明潜在影响面很大，但近 70% 的网站并没有被证明可以用同一种方式攻破。

为什么这次修复特别难

PHP 的部署形态极其分散。一个企业可能同时拥有几套不同来源的运行时：云镜像里的 PHP-FPM、旧版 Apache mod_php、某个控制面板捆绑的解释器、容器基础镜像、遗留任务机上的 CLI，以及 SaaS 设备中看不见的嵌入式组件。

PHP 官方列出的风险范围包括 PHP-FPM、mod_php、php-cgi、FrankenPHP 和 LiteSpeed，并认为 mod_php 风险最高，因为已有演示显示攻击可以在应用代码运行之前触发。因此，WordPress 插件升级、Drupal 模块更新或应用层身份验证都不能替代运行时补丁。

支持周期让问题更复杂。PHP 8.2–8.5 有明确的上游修复版本；8.1 及更老分支不再由 PHP 项目正常维护。PHP 团队为 7.4、8.0 和 8.1 提供了最小源代码回移，帮助自行构建或缺少 LTS 供应商支持的用户，但实际生产环境仍要依赖发行版、托管商或设备厂商把补丁做成可安装的软件包。

图 3：上游固定版本与旧分支处理边界。发行版回移可能保留旧版本号，不能只看字符串判断。

补丁安装后还不算结束。PHP-FPM 与 Apache worker 必须重启，容器要重新构建并滚动替换，长时间运行的进程要确认已加载新二进制。只更新磁盘上的软件包，却让旧 worker 继续服务，请求路径仍可能停留在修复前的代码上。

所谓“互联网修复速度”，要把资产发现、供应商交付、变更审批、部署窗口、进程重启和结果验证全部算进去，下载补丁只占其中很小一部分。

Defender's Window 为什么只剩九小时

OpenAI 把“前沿模型先于攻击者发现漏洞”带来的领先时间称为 Defender's Window。PHP2Shell 的协调过程证明，这个窗口确实存在：维护者提前修复，云厂商和安全厂商提前准备规则，发行版与 LTS 供应商提前拿到补丁。

但窗口并不稳定。

Cloudflare 表示，漏洞信息在官方发布前发生泄露。其 WAF 规则从 10 月初开始开发，并于 10 月 21 日 03:02 UTC 向使用 WAF 的免费与付费客户默认部署，距离公开披露约九小时。更重要的是，Cloudflare 当时已经观察到针对客户的攻击流量，以及攻击者为绕过防护而进行的变形尝试。

图 4：Cloudflare 公布的防护窗口。WAF 提前上线争取了时间，但官方仍要求升级 PHP。

这段时间线说明了两个事实。

第一，协调披露仍然有价值。没有提前共享，Cloudflare 不可能在公开前准备需要结合请求与响应信号的 full transaction detection，发行版和托管商也无法同步准备更新。

第二，保密窗口一旦收缩，攻击自动化可能快过企业部署。公开补丁本身也会暴露差异，帮助攻击者定位修复区域。当前沿模型让漏洞分析和跨版本适配更便宜时，攻击者不必拥有最顶尖的内存安全团队，也可能快速追上。

WAF 在这里扮演的是缓冲层。Cloudflare 甚至需要观察同一 HTTP 交易的请求与响应，才能在控制误报的同时提高检测信心。这类保护能阻挡已知路径、争取升级时间，却不能证明源站已经安全。新的变体、绕过和未覆盖部署仍然存在。

Defender's Window 的价值，是让组织在补丁到达之前不至于毫无防备。

AI 正在改变漏洞研究的成本

过去，一条复杂的内存破坏链可能长期停留在“理论上有问题、现实中很难利用”的灰色区域。要把它变成跨版本、跨应用的稳定证明，研究者需要反复搭环境、调试内存布局、理解大量遗留代码，还要验证修复没有引入回归。

Wiz 的判断是，前沿模型显著降低了这部分成本。其团队称，原本可能需要顶尖团队投入数月的工作，现在可以由一名研究者在更短时间内推进。这个说法来自研究方自身，不能自动外推到所有漏洞；但 PHP2Shell 至少证明了一点：复杂度不再是可靠的安全屏障。

这对防守方是好消息。老代码库里长期潜伏的问题可以更系统地被找到，补丁验证、版本盘点和检测工程也能得到 Agent 帮助。OpenAI 发布的 PHP 版本检查 Skill 就是一个例子：它不发送利用请求，只读取本机版本或公开响应头，用来快速筛查可能受影响的运行时。

但该工具的限制同样值得写进文章。服务器可以隐藏或伪装版本头；发行版可能把补丁回移到旧版本号；UNKNOWN 不代表安全；仅凭外部 HTTP 响应也无法发现内网 worker、后台任务和不对外暴露的容器。

AI 能让“先找出可能有问题的地方”更快，却无法替代最终的资产责任人。

图 5：一次核心运行时漏洞要经过研究、维护、供应商与企业多层传递，任何一层掉队都会缩短防守窗口。

模型越来越能读懂代码，剩下的瓶颈却集中在下面这些普通、也更难自动解决的问题：

• 开源维护者是否有时间处理突然增加的高质量报告；
• 谁可以提前获知漏洞，同时又不扩大泄露面；
• 旧分支由谁回移，谁承担测试与发布责任；
• 托管商和设备厂商能否在客户不操作的情况下完成更新；
• 企业是否知道自己到底运行了多少套 PHP；
• 补丁之后，谁来确认所有 worker、容器和镜像真的换新；
• 事件团队是否检查了披露前后可能留下的异常痕迹。

这些工作听起来不如“AI 发现 0day”精彩，却决定了漏洞公告之后会发生什么。

给企业的行动清单

如果组织里有任何面向 Web 请求的 PHP 运行时，优先级很清楚。

1. 先升级，不要把 WAF 当补丁

升级至 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35。使用 Linux 发行版、LTS 厂商、托管平台或商业设备时，应按照供应商公告确认回移包。PHP 8.1 及更老版本需要确认供应商是否提供修复；没有可靠来源时，迁移到受支持版本。

2. 重启并验证正在运行的进程

重启 PHP-FPM、Apache、LiteSpeed 或相关容器 worker。验证的是运行中的进程，不是软件包管理器显示的安装版本。容器环境还要重建基础镜像，替换旧副本，并检查定时任务、队列消费者和后台 CLI。

3. 做一次完整的资产盘点

检查互联网入口只是第一步。还要覆盖容器注册表、旧虚拟机、控制面板、开发与灾备环境、供应商 appliance，以及被反向代理隐藏的内部 PHP 服务。外部版本检查返回 UNKNOWN 时，不能当作已修复。

4. 暂时无法升级时，只把缓解当作争取时间

PHP 官方给出了针对特定路径的临时设置，例如限制请求体规模、关闭不需要的上传进度功能，并在 PHP 8.5 中关闭致命错误 backtrace。每项都可能影响业务，需要在配置层正确应用并重启 worker。官方同时强调：这些措施无法覆盖所有变体。

5. 保留 WAF 与运行时监控

即使完成升级，也应继续观察异常请求、进程崩溃、worker 重启频率、Web 进程派生子进程、异常网络连接和敏感文件变更。WAF 是纵深防御，运行时与主机遥测则帮助判断是否已经发生异常。

6. 复盘“从公告到完成”的时间

记录组织用了多久完成识别、供应商确认、变更审批、部署、重启和验证。如果一个 CVSS 9.2 的核心运行时漏洞仍需要数天才能确认资产范围，那么下次 AI 更快找到漏洞时，风险不会因为模型更强而自动下降。

图 6：修复完成应包括升级、重启、盘点、验证和监控，不能停在“包已安装”。

发现只是起点

PHP2Shell 给了 AI 安全研究一个很强的正面案例。前沿模型帮助研究者跨过了复杂度门槛，为维护者争取了修复时间，也让多个基础设施提供商可以在公开披露前准备保护。

它也给出了同样清晰的警告：发现能力可以按算力和 Agent 数量扩张，开源维护、供应商回移、企业变更窗口和资产责任却不会自动扩容。

以后我们会看到更多类似事件。衡量防守能力的指标，也不能只看“AI 又找到了几个漏洞”。更重要的是：从第一个可信报告出现，到最后一个关键生产 worker 重启并完成验证，整个系统用了多久？

模型可以把漏洞发现的时钟拨快。最后决定结果的，仍是修复链条里最慢的那一环。

参考资料

1. PHP 官方安全公告与版本发布：https://www.php.net/^[1]
2. OpenAI，Patch the Planet：https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/^[2]
3. Cloudflare，PHP2Shell WAF protection：https://blog.cloudflare.com/php-vulnerabilities-waf-protection^[3]
4. Wiz Research，PHP2Shell technical research：https://www.wiz.io/blog/php2shell-php-rce^[4]
5. PHP2Shell 联合信息页：https://www.php2shell.com/^[5]
6. Imperva PHP2Shell advisory：https://php2shell.imperva.com/^[6]
7. OpenAI PHP version checker：https://github.com/openai/php2shell-checker^[7]

引用链接