PHP大暴雷！两个Critical漏洞直击引擎，AI参与发现与修复

发布日期：2026年10月22日 | 来源：PHP、OpenAI、Wiz、Calif 官方资料

这次不是某个 WordPress 插件出了问题，而是 PHP 引擎自己出了问题。

10 月 21 日，PHP 项目突然放出一则高危安全公告，同时发布 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 四个修复版本。公告确认，两个 PHP 核心漏洞可能让不需要登录的攻击者直接在服务器上执行代码。

PHP 官方的态度也很明确：没有完整的缓解措施，更新才是安全的解决办法。还在用 PHP 8.1 或更早版本的团队，需要马上查发行版或 LTS 厂商有没有回移植补丁；PHP 项目本身已经不再为这些分支提供常规更新。

一夜之间，PHP 服务器都得重新盘一遍

这两个漏洞的编号是 CVE-2026-109618 和 CVE-2026-109619。PHP 仓库对应的 GHSA 安全公告把它们都列为 Critical，CVSS v4.0 评分为 9.2；NVD 采用另一套评分体系，给出的 CVSS v3.1 分数是 9.8。

风险面也不是“升级某个 CMS”这么简单。PHP 官方列出的部署形态包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 和 LiteSpeed，其中 mod_php 风险最高。官方已经看到过未认证请求在应用代码运行之前触发攻击路径的演示。

Wiz 把这次研究称为 PHP2Shell。Wiz 报告称，过去十年发布的 PHP 版本至少有一个漏洞受影响，最早的影响路径可以追溯到 PHP 5.4；报告标题和摘要还使用了“约 70% 的互联网”这一说法。这个数字是 Wiz 的影响范围估算，不能直接当成所有网站都已暴露。

更麻烦的是，漏洞在 PHP 引擎里。Wiz 在 WordPress、Drupal 和 Joomla 的最新容器上演示了未认证 RCE，但这些 CMS 只是展示目标，换成一个很简单的 PHP 页面，也可能落在同一条底层风险路径上。

PHP 到底哪里坏了

第一条漏洞可以简单理解成：PHP 在内存不够时，写了一半的数据结构就被迫停下来了，但后面的清理流程仍然把它当成完整结构处理。

第二条漏洞则像是请求结束后，PHP 已经把一块内存释放掉了，却还在 worker 里留着指向这块内存的状态。下一个请求进来时，如果初始化还没来得及覆盖它，程序就可能继续使用这份陈旧状态。

这两种情况都属于内存安全问题。它们不一定每次都直接变成远程代码执行，但研究人员可以把内存泄露、状态残留和内存破坏串成攻击链，最终拿到服务器上的代码执行能力。

所以，应用日志里可能没有一个特别醒目的“漏洞触发”提示。Wiz 建议重点留意异常 multipart 请求、内存限制错误之后连续出现的 HTTP 500、异常偏大或格式异常的 PHPSESSID Cookie，以及 PHP worker 无解释重启或频繁退出。

最容易被误传的一句话：不是 ChatGPT 单独发现的

这次事件在社交媒体上最吸睛的说法是“ChatGPT 发现了 PHP 超级漏洞”。但按官方披露，事情要复杂得多。

OpenAI 说，Calif 在 Patch the Planet 计划中使用 GPT-5.6 Sol 发现了一个关键缺陷；Wiz 则独立发现并报告了这两个漏洞。 Wiz 的研究过程中还使用了 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol，并特别提到 Gemini 4 Argon 对漏洞发现、利用开发、攻击检测和补丁验证都有重要贡献。

换句话说，AI 是研究工具的一部分，不是一个模型单独完成了“发现、利用、写补丁、上线”全流程。PHP 维护者负责确认问题、设计修复和发布版本，OpenAI、Wiz、Calif、Cloudflare 等团队在披露前提供研究、测试、检测和协调支持。

这件事的时间线也很能说明问题：2024 年的外部审计重新发现了 OOM 线索；2026 年 8 月 Calif 和 OpenAI 报告了相关路径，Wiz 随后独立报告并验证了 RCE；9 月 PHP 维护者开始协调修复；10 月 21 日，补丁和公开披露一起到位。

OpenAI 把这种“在攻击者之前发现问题、给维护者留出修复时间”的阶段称为 Defender’s Window。但这个窗口正在变短：AI 能帮助防守方更快找漏洞，也能降低攻击者适配复杂攻击链的门槛。

现在该怎么办

先不要只看容器标签，也不要只检查命令行里的 PHP。Web 服务器实际调用的 SAPI 可能仍然是旧版本。可以在入口节点和 PHP worker 环境里分别确认：

php -r 'printf("version=%s sapi=%s\n", PHP_VERSION, PHP_SAPI);'
php --ini

然后按这个顺序处理：

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 及更早版本，查询发行版或 LTS 厂商的回移植补丁；源码构建用户可以核对 PHP 安全团队提供的 7.4、8.0、8.1 最小 backport。
升级后重启所有 PHP worker，再次确认版本和 SAPI。不要出现“CLI 已升级，Web 进程还在跑旧版本”的情况。
如果暂时无法升级，可以按 PHP 公告关闭 session.upload_progress.enabled；PHP 8.5 还可以关闭 fatal_error_backtraces，并限制请求体和 multipart 规模。这些设置只能降低已确认路径的风险，不能代替补丁。
发现异常请求、连续 500 或 worker 异常退出时，先保存日志和进程证据，再按事件响应流程处理。不要在生产环境运行公开的利用脚本来“验证”漏洞。

WAF 和边界规则可以作为额外防线，但不能替代 PHP 核心升级。Cloudflare 已说明其 WAF 防护只能争取处置时间，PHP 官方修复仍然是最终动作。