PHP2Shell 与 AI 时代的漏洞响应：发现更快，谁来证明修复生效？

一家团队可能更新了全部 WordPress 插件，却仍让有漏洞的 PHP 工作进程处理公网请求。PHP2Shell 让这种落差变得具体：问题出在应用之下的运行时，而负责网站的人未必直接管理它。

PHP2Shell 涉及两项 PHP 核心漏洞，CVE-2026-109618 和 CVE-2026-109619，CVSS v4.0 评分均为 9.2。研究人员在有代表性的应用环境中演示了未经身份验证的远程代码执行，也单独演示了读取 PHP 进程内存中的敏感信息。WordPress、Drupal 和 Joomla 是演示目标，并非唯一可能受影响的应用。具体服务是否暴露，还取决于实际运行的 PHP 版本及配置。PHP 官方安全公告 · Wiz 研究报告

本文依据截至 2026 年 10 月 22 日的公开资料分析，没有复现漏洞，也不能据此判断某个具体网站已经遭到入侵。

时间线依据 PHP Foundation 的事件复盘、Wiz 的研究时间线及 PHP 官方发布公告整理。图中的 9–10 月表示持续协作，并非某一天才开始修复。

一个老问题，终于有了无法忽视的利用证据

这件事并不是 AI 第一次看见一段无人知晓的代码。2024 年的一次安全审计期间，PHP 开发者已发现其中一项漏洞背后的内存耗尽问题的早期迹象。彼时有人提出可能的利用方向，却还没有明确的远程攻击路径。几种修法又各有代价：可能破坏兼容性、引入可用性问题，或要求第三方扩展一起调整。修复工作由此停滞。PHP Foundation 将延误归因于决策机制和维护资源两方面的问题。PHP Foundation 复盘

到 2026 年 8 月，Calif、OpenAI 和 Wiz 陆续提交研究结果，漏洞的实际后果变得清楚。OpenAI 表示，Calif 在研究中使用了 GPT-5.6 Sol；Wiz 则表示，在发现、利用验证和补丁核验过程中使用了 Wiz Atlas、Gemini 4 Argon 与 GPT-5.6 Sol。这些是参与方对研究方式的说明，不意味着模型独立完成安全裁决或交付了可以直接上线的补丁。修复与发布仍由 PHP 维护者主导。PHP Foundation 复盘 · OpenAI 协作说明 · Wiz 研究报告

Wiz 公布的时间线让这段过程更具体：团队称在 8 月 19 日发现首个漏洞，20 日在 Drupal 上确认未经身份验证的代码执行，21 日又在 WordPress 上确认，并于 24 日向 PHP 团队报告。研究还演示了不依赖特定应用的 PHP 工作进程内存读取。在他们的研究中，这帮助降低了构造其他利用链时对内存布局的猜测。这些是选定环境中的演示，不等于已经测得现实中有多少网站可以被攻破。Wiz 研究与披露时间线

AI 在这里更明确的作用，是缩短了从“这里可能有问题”到“能够证明实际影响”之间的距离。不同 PHP 版本、请求顺序和部署环境，都会改变内存行为。Wiz 描述了模型如何结合测试与调试工具，分析失败结果、调整方案，并特别提到 Gemini 4 Argon 参与了漏洞发现、利用开发、攻击检测和补丁验证。Wiz 称其团队在数小时内为多个应用调整出可运行的演示；这是该团队对本次研究的描述，不是自动化利用速度的通用基准。防守方可以借此更早调查积压已久的缺陷，攻击者也可能在漏洞公开后更快调整利用方式。但这并不意味着每台受影响服务器都已遭到攻击。Wiz 研究报告

消息跑得比补丁快

10 月 20 日，漏洞编号在原定发布日期之前流传。PHP 团队提前发布预告，并将安全更新从 10 月 22 日提前至 10 月 21 日 14:00 UTC。PHP Foundation 称，最初泄露的信息并未包含完整技术细节；此后误发的演示视频和提前出现的修复镜像又增加了压力。与此同时，发行方仍需要时间制作可供用户安装的软件包。因此，10 月 20 日是提前预警，而不是完整公告和修复版本的发布日期。PHP Foundation 披露时间线

这段时间差指出了 AI 无法独自解决的瓶颈。发现漏洞只是第一步；维护者要在不破坏生态的前提下修复根因，发行版和托管商要交付软件包，运营团队还要把它部署到每个相关运行时。警报可以迅速传遍网络，经过验证的补丁却不会自动出现在正在工作的进程里。PHP Foundation 复盘 · OpenAI 协作方案

怎样才算真正修好

PHP 官方列出的已修复版本为 8.5.12、8.4.27、8.3.36 和 8.2.35。PHP 8.1 及更早版本不再获得上游常规安全发布；发行版或长期支持供应商可能回移补丁，但必须核对实际使用的软件包是否包含修复。否则，服务需要迁移到受支持的版本。PHP 官方安全公告

比“网站更新了吗”更有用的问题是：“现在究竟由哪个 PHP 进程处理公网请求，凭什么确认它已经修复？”容器标签、开发者电脑上的 php -v、CMS 更新记录，都不一定能说明线上 Web 工作进程的状态。托管环境可能由服务商负责运行时；自定义镜像则可能需要客户自行重建和部署。先查清责任归属，才能诚实地把事件标为已处置。Google Cloud 对不同运行时的说明 · PHP 官方安全公告

WAF 和运行时监测可以在补丁部署期间降低部分暴露面、帮助发现异常，但不能证明 PHP 引擎已经修复。即使规则拦住了可疑 HTTP 响应，也撤销不了源站此前可能执行的操作。2FA 和防钓鱼保护的是其他环节；修改应用代码或插件，也不会修复 PHP 核心的内存漏洞。Cloudflare WAF 分析 · PHP 官方安全公告

留下来的问题

PHP2Shell 与其说是模型之间的竞赛，不如说是对整条响应链的检验。AI 辅助研究让多年前的疑点有了实际影响的证据；人类维护者完成了艰难的修复；服务商和运营团队仍要查明 PHP 跑在哪里、谁负责更新，以及修复后的进程是否真的在处理流量。