AI挖出PHP十余年重大漏洞:全球网站紧急修补,OpenAI与Google旗下团队参与发现

两个 CVSS 9.2 级 PHP 核心漏洞，四个紧急修复版本。AI协助研究人员验证了多年未解的内存风险，也让全球基础软件的修补窗口受到新的考验。

2026年10月21日，PHP开发团队一次性发布四个安全更新，修复两项存在于语言运行时核心的严重漏洞。两项漏洞均被评为CVSS v4.0 9.2分，在特定条件下可能使攻击者无需登录便在服务器上执行代码。欧洲部分政府与公共服务网站暂停访问或启动紧急维护，网络安全机构呼吁管理员尽快修补。

这次事件被安全社区称为“PHP2Shell”。其特殊之处不止在于影响范围：Calif研究人员借助OpenAI的GPT-5.6 Sol，Wiz团队借助Gemini 4 Argon、GPT-5.6 Sol与自有工具，推动了漏洞的发现、验证和修复测试。PHP基金会在官方复盘中承认，相关问题在2024年就已出现过技术迹象。

从长期未解的底层内存问题，到2026年集中爆发的修补行动，这起事件展示了前沿AI正在怎样改变基础软件安全研究，也暴露出开源基础设施维护的现实压力。

漏洞位于PHP引擎，而不只是某个网站插件

PHP是一门长期用于网站后端的开源语言，WordPress、Drupal、Joomla以及MediaWiki等软件都依赖其运行。PHP自身出现漏洞，与某一主题、插件或应用程序代码出现缺陷，影响层级完全不同：即便上层业务逻辑没有明显问题，运行时仍可能成为攻击入口。

本次公开的编号为CVE-2026-109618和CVE-2026-109619。PHP官方指出，PHP-FPM、Apache mod_php、php-cgi、FrankenPHP和LiteSpeed等部署形态都需要评估风险，其中mod_php具有不经过应用代码即可触发的已验证路径。Wiz在WordPress、Drupal、Joomla等实验部署中复现了远程代码执行和进程内存读取风险。

一些报道引用“约70%的网站使用PHP”，其来源实际是可识别服务端编程语言的网站占比估计。这个数字不能解释为70%的网站已被攻击，甚至不能直接推断70%的互联网服务都满足相同利用条件。确认受影响范围仍须检查实际PHP版本、运行模式与暴露情况。

两项9.2分漏洞，共同指向内存与错误处理

CVE-2026-109618涉及内存耗尽（Out-of-Memory，OOM）时的状态损坏：当请求在内部数据尚未完整初始化时被异常中断，后续清理过程可能把失效数据当作有效对象处理。

CVE-2026-109619则与致命错误后遗留的内部状态有关。部分状态指向的内存已经释放，但工作进程仍保留相关引用；当同一进程处理后续请求时，可能出现跨请求使用已释放内存的问题。

两者都属于底层内存安全问题，和常见的SQL注入、前端脚本漏洞不同。Wiz报告中披露的安全后果包括敏感进程内存泄露及未经授权的远程代码执行。对部署者而言，重要的并非复现具体利用细节，而是认识到这些风险可能发生在PHP处理请求的通用路径中，无法单靠修补某个CMS插件解决。

AI的贡献具体发生在哪里？

OpenAI在10月21日发布的说明中确认，Calif通过GPT-5.6 Sol识别了关键缺陷，Wiz也独立报告两项漏洞。Google Cloud与Wiz的技术文章则指出，Wiz结合Wiz Atlas、Gemini 4 Argon和GPT-5.6 Sol开展研究，Gemini 4 Argon在漏洞发现、利用可能性验证、检测方案和补丁验证中发挥了重要作用。

因此，这不是“某一个模型独自破解PHP”的故事。不同研究团队使用不同模型与安全工具，完成代码分析、条件验证、交叉测试和变体排查。真正发布补丁的是PHP维护团队，多家云服务、CDN和安全厂商则参与协调防护与发布准备。

更有代表性的变化在于复杂问题的研究成本。内存错误往往依赖特定进程状态和版本差异，传统研究需要大量手工调试。前沿模型能协助追踪代码路径、解释失败结果、缩短实验反馈周期。AI降低的是部分分析和验证成本，并不能取代维护者对兼容性、性能和最终补丁质量的判断。

2024年就有迹象，为何直到现在才修复？

PHP基金会的复盘提供了这起事件最值得反思的背景。2024年外部安全审计之后，开发人员就发现了OOM处理中的潜在问题，也讨论过可能被利用的情形。但当时没有找到明确、可复现的攻击路径，修复方案还涉及向后兼容、拒绝服务风险，以及第三方扩展是否需要随之改动等取舍。

直到2026年8月，Calif、OpenAI与Wiz先后提供更完整的技术证据，安全团队才把相关根因修复提升为最高优先级。基金会承认，这暴露了过去在风险升级、工程资源和跨团队决策上的不足。

一个漏洞是否“已知”，与其是否被认为“值得立即大规模修复”，之间常隔着可利用性的证明。AI研究工具正在缩短这段距离，但如果开源基础项目没有足够的专职维护人员，发现速度提高也可能让积压的修复工作更加突出。

提前泄露打乱披露节奏，防守窗口正在缩短

按照PHP基金会披露的经过，10月20日，两项CVE编号提前在网络传播，随后部分概念验证相关信息外泄。协调披露计划因此调整，PHP最终在10月21日正式发布修复版本。

披露过程还有一处敏感事件：一家已提前获得补丁的发行方，在正式公开前发布了包含修复内容的镜像。这会让潜在攻击者有机会通过比对二进制差异分析修复点，而大量用户尚未收到可直接安装的稳定更新。

需要区分的是，Wiz已在受控环境复现攻击，网络上也出现了尝试和概念验证传播；但PHP基金会明确表示，其团队在正式发布时尚未确认存在可用的公开攻击程序。研究复现、尝试利用和真实入侵规模不是同一回事。

这场协调工作的核心难题是：越早提醒运营者越能争取修补时间，但越早释放过多细节，也可能给攻击者提供线索。随着AI降低漏洞分析门槛，这个平衡会越来越难。

哪些版本必须更新？网站管理员现在应做什么？

PHP官方于10月21日发布PHP 8.5.12、8.4.27、8.3.36和8.2.35，分别覆盖目前受支持的四个分支。PHP 8.1及更早版本已经不再获得PHP项目的常规官方安全更新，使用这些分支的系统需要制定升级计划，或核对发行版、托管商是否提供了单独回移修复。

运维团队应核对线上实际运行时版本，而不只是本机命令行PHP版本；盘点网站、容器、应用服务器与镜像中的所有PHP实例；备份后按照发行版或云服务商的更新指引部署修复，并确认工作进程已重新加载新版本。

WAF规则、CDN策略和临时流量控制可以作为过渡保护，却不能替代运行时更新。对无法及时修补的公开服务，安全机构建议根据业务影响评估临时下线或限制暴露面，并检查异常请求、错误日志和工作进程行为。

PHP官方强调，目前没有能够完全替代升级的缓解措施。对于WordPress等托管应用，管理员还应确认托管服务商是否已经完成底层PHP升级；只更新CMS本身并不等于运行时漏洞已经修复。

这不是“AI打败程序员”，而是软件安全的成本结构在变化

两项漏洞已存在多年，2024年出现过线索，2026年在多家研究机构与前沿模型共同参与下完成可利用性验证，并最终促成紧急修复。这条时间线更准确地呈现了AI的作用：它放大了安全研究人员的能力，也加快了复杂缺陷从“理论上可能”到“现实中可验证”的转变。

但同一组能力具有双重用途。防御者能够更早识别底层风险，攻击者也可能更快理解已经公开的补丁差异。安全竞争的关键正在从“能否发现漏洞”，延伸到“发现后能否迅速验证、修复并完成大规模部署”。

真正决定互联网安全基础设施韧性的，仍是维护团队、协调机制、发行版生态和持续工程投入。PHP基金会在公告中特别呼吁更多长期资助：AI可以帮助找出问题，承担兼容性权衡和补丁维护责任的工程师却依然稀缺。