TL;DR
10 月 21 日，PHP 发布计划外紧急安全更新，修掉核心引擎里两个潜伏超过十年的内存安全漏洞（CVE-2026-109618 / CVE-2026-109619，CVSS v4.0 评分最高 9.2，安全圈统称 PHP2Shell ）。它们能让你服务器的 PHP 进程被不需要登录的攻击者直接执行任意代码 ，或者偷走内存里的密码、token 和 API key。PHP 驱动着全球约 70% 的网站，WordPress、Drupal、Joomla 全部中招。最有意思的是：这漏洞在代码里躺了十几年没人能稳定利用，最后是前沿 AI 模型把它变成了现实武器------同时也把它变成了能被及时修好的漏洞。NSA 的建议简单粗暴：打不上补丁的网站，先下线。
先说清楚发生了什么
10 月 21 日 13:30（UTC），PHP 一次放出四个分支的紧急更新：8.5.12、8.4.27、8.3.36、8.2.35。同一天，Wiz Research、OpenAI、PHP Foundation、安全公司 Calif 四方几乎同时发博客，NSA、CISA、英国 NCSC、加拿大网络安全中心、CERT-EU 相继发紧急公告------这个阵仗，上一次出现还是 Log4Shell。
要修的东西是两个内存安全漏洞（use-after-free，用后释放）。通俗讲：PHP 处理请求中途出错（比如内存耗尽）时会异常退出，但退出时没把"案发现场"收拾干净，给下一个请求留下了一块被污染的内存。攻击者精心构造请求，让后续请求把这堆垃圾当成有效数据用------轻则把别的用户请求里的密码、token 原样吐给你（内存泄露），重则完全控制服务器进程（远程代码执行）。
这里需要澄清一个容易误读的点：漏洞不在 WordPress 也不在你的应用代码里，而在 PHP 本体。Wiz 用最新镜像实测，WordPress、Drupal、Joomla 全部被打穿，哪怕你的网站只输出一句 Hello World，只要跑在受影响版本的 PHP 上就一样危险。WordPress 官方也专门发声明澄清了这一点，让站长去催自己的主机商。
漏洞躺了十几年，为什么现在才爆？
这是整个事件最值得琢磨的部分。
这两组漏洞的根因可以追溯到 PHP 十多年前的架构决策，PHP 5.4 之后的每个版本至少命中其一。换句话说，它们不是"新出现的漏洞"，而是"一直都在、只是没人打得动"的漏洞。构造一个能在真实服务器上稳定工作的利用链，要串起多个小漏洞、适配不同 PHP 版本的内存布局、跨配置调试------这种活儿以前只有世界级研究团队愿意碰，一做就是几个月。
AI 把这笔账改写了。Wiz 的研究员配合 Wiz Atlas、谷歌的 Gemini 4 Argon 和 OpenAI 的 GPT-5.6 Sol，一名研究员用一周时间走完了过去一个团队数月的路：8 月 19 日发现漏洞，8 月 20 日在 Drupal 上验证未认证 RCE，8 月 21 日打穿 WordPress。Gemini 安全负责人 Raluca Ada Popa 罕见地公开为 Argon 的贡献背书。
无独有偶，几乎同一时间，安全公司 Calif 在 OpenAI 的「Patch the Planet」计划里用 GPT-5.6 Sol 独立发现了其中一个漏洞。两边一对照，PHP 团队发现这两个团队报告的问题同根同源，最后合并成两个 CVE。
Wiz 在博客里把话说得很直白：过去大家默认"这个漏洞太复杂，短期内没人能利用"就是安全垫，现在这层垫子没了------LLM 能快速把利用代码适配到不同版本、不同配置、不同内存布局上，复杂度本身不再构成安全屏障。哪些"理论风险"要当真，评价标准得重写。
修复与响应：一场两小时的全球动员
时间线值得看一眼，因为它展示了 AI 时代漏洞响应的新形态：
- 8 月 19 日 ：Wiz 用 AI 工具链发现首个漏洞；8 月 24 日报告 PHP 安全团队。
- 9 月 21 日：PHP 团队确认并启动协同修复。此后两个月，OpenAI 牵头组了一个包含 PHP 维护者、安全研究员、云厂商的响应联盟。
- 10 月 20 日：CVE 编号与技术细节提前泄露（各机构公告确认了这一点），PHP 官方被迫提前预告将有紧急更新，Hacker News 当晚炸出 152 条讨论。
- 10 月 21 日 13:30 UTC：四个分支修复版同时发布；四方官方博客协同披露；NSA、CISA、NCSC、CERT-EU 同日发告警；Cloudflare、Fastly、Google Cloud、AWS、Azure、Vercel 的 WAF 缓解规则当天上线。
需要澄清的是：OpenAI 强调漏洞是研究者先于黑客发现、披露前没有野外利用报告------这一点目前没有反例，可以认为是可信的。但"提前泄露"确实把两个月协调期里最后的安全余量烧掉了，社区对此颇有微词（后面细说）。
各机构的建议按严厉程度排：CISA 说"立即打补丁"；NSA 说"打不上补丁就先下线"；对还在用 PHP 8.1 及更老版本的站点，补丁根本不存在------那些版本已经停止支持，得先升级 PHP 本身。这也是国内大量存量站点最现实的风险：老版本 PHP + 无法快速升级 = 长期暴露。托管在主流云上的可以先用云 WAF 的虚拟补丁顶一阵，自建机房没有退路。
各方怎么看
官方层面动作一致，社区层面的分歧倒是值得展开。
Hacker News 上的主讨论（404 分）里，点赞很高的批评指向披露流程：OpenAI 和安全公司"捂了两个月，自己决定谁能提前拿到修复，PoC 一上线，圈子外的用户就被晾在那儿"。批评者的意思是------既然官方临时缓解方案（针对 8.5 的 interim fix）早就能做出来，为什么不提前发？AI 把利用门槛降下来之后，两个月的静默期还是不是合理的安全预算，这笔账确实该重算。
技术社区也没闲着：有人逐行分析泄露的 PoC，认为它对 PHP 8.4 的假设可能不成立（这条尚未有权威定论，姑且存疑）；还有人发现可能存在第三个 critical CVE（PHP 官方未确认，同样存疑）。这些讨论本身说明：细节公开后，全球的研究者都在帮 PHP 查漏补缺------从防御视角看，这算坏事里的好事。
OpenAI 自己则把这当作「Patch the Planet」计划的标志性战果来宣传：AI 发现问题、AI 组织全球响应，顺带宣布了 10 亿美元的防御者补贴计划和一枚检测 PHP 版本的 Codex skill。商业叙事归商业叙事，"前沿模型既能造武器也能造疫苗"这个判断，倒是这事件里最没有争议的部分。
对开发者意味着什么
- 运维 PHP 站点的 ：今天就把
php -v跑一遍。8.2.x/8.3.x/8.4.x/8.5.x 升到对应修复版（8.2.35 / 8.3.36 / 8.4.27 / 8.5.12）；8.1 及以下的先升级 PHP 再谈补丁；实在动不了的，先套 WAF 虚拟补丁并评估是否临时下线。Sophos 的公告还提醒：Apache mod_php 部署形态风险最高。 - 写安全工具 / 做风控的：Wiz 给了检测线索------异常的 multipart 请求紧跟内存超限错误或连续 500、异常大的 PHPSESSID cookie、无解释的 PHP worker 重启。这些信号值得进你的告警规则。
- 所有写代码的：这件事的长期影响比补丁本身大------"我们太冷门/太复杂所以没人利用"的假设失效了。存量代码里那些"理论上可利用但没人会费劲"的洞，都值得按新的利用成本重新评估一遍。
参考来源
- Wiz Research 技术报告：php2shell
- OpenAI 官方博客：Patch the Planet
- PHP Foundation 官方公告：今日安全更新与安全强化计划
- CISA 紧急公告：Critical Vulnerabilities in PHP
- CERT-EU 公告 2026-018：Critical Vulnerabilities in PHP
- TechCrunch 报道：PHP armageddon
- The Verge 报道：GPT-5.6 Sol was used to identify critical PHP flaw
- Sophos 安全公告：PHP2Shell Vulnerabilities
- Hacker News 社区讨论：主讨论帖