事件与背景

11 月 2 日，IEEE Spectrum 发了一篇标题很直白的文章：AI is forcing us to pay off 40 years of technical debt。它讲的是 PHP 核心引擎里的一组漏洞——PHP2Shell。文章在 Hacker News 首页拿到 772 分、474 条评论，是这两天技术圈讨论度最高的一条。

漏洞本身由 Wiz Research 公布，编号 CVE-2026-109618 与 CVE-2026-109619，CVSS 最高 9.2。两组问题都出在 PHP 自己身上，而不是某个 CMS 插件：一组是处理请求时发生内存耗尽（OOM）致命错误后，请求堆被销毁却留下未定义的全局指针；另一组是 worker 跨请求复用陈旧状态，形成 use-after-free。后果有两种——未认证攻击者可以直接在服务器上执行代码，或者读到 PHP 进程内存里的密码、会话 token、API key 和证书。

Wiz 在 WordPress、Drupal、Joomla 的最新容器镜像上实测了未认证 RCE，但也明确说：漏洞在 PHP 引擎层，跑一个 Hello World 也一样中招。受影响范围是过去十年发布的几乎所有 PHP 版本，最早可追到 5.4；按 Wiz 的说法，PHP 支撑着约 70% 的网站。

AI 在这里不是配角。Wiz 全程使用 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol，其中 Argon 在”找漏洞、开发 exploit、验证补丁”三处都被点名。他们的总结是：这条利用链需要串联多个缺陷、并且针对每个目标的内存布局反复调试，“在 AI 之前，这种手工工作极难实现，更难规模化”；而现在，一个研究员一周就完成了过去世界级团队要做数月的工作。

修复侧的数字更能说明问题：PHP 团队 4 名工程师做了两个月，补丁触及 390 个文件——因为修复方式是把”内存硬上限”改成”软上限 + 延迟抛出 fatal error”，而这要求每一个分配内存的 C 函数都不再假设”分配失败会立刻 longjmp”。修的是同一个隐含假设，而没人能把它同时装进 390 个文件的脑子里。

已修复版本：8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。

来源（均已用 curl 验证返回 200）：

• IEEE Spectrum：PHP2Shell Is a Wakeup Call for AI in Cybersecurity
• Wiz Research：PHP2Shell 技术分析（含 CVE、利用链与模型分工）
• php2shell.com：官方修复版本表与缓解措施
• AWS Security Blog：MadPot 在公开披露前 4 天已观测到利用尝试
• Alexandre Daubois：来自 PHP 安全团队内部的谣言勘误

为什么现在重要

1. “漏洞复杂度”作为防线的时代结束了。 内存破坏类漏洞过去被视为天然门槛：能写 exploit 的人少，所以补丁可以慢慢打。Wiz 的说法是模型能把一份 exploit 适配到不同 PHP 版本、配置和内存布局上。影响：以”这个洞太难利用”为由降级排期的做法，从今天起都不成立。

2. 时间线已经不是”披露日开始算”。 AWS 的蜜罐网络 MadPot 在 10 月 17 日就抓到了针对 PHP2Shell 的利用尝试，比原定 10 月 21 日 14:00 UTC 的解禁时间早四天，来源是商用匿名化网络的 IP。披露当天 02:00 UTC 起，多个不同来源的 PoC 和攻击尝试陆续出现。影响：如果你的应急响应从”公告发布时间”开始回溯日志，你已经漏掉了最关键的窗口。

3. 补丁到 exploit 的间隔被压到小时级。 AWS 写得很直接：过去大多数利用发生在公开 PoC 之后，少数高手做、其余人等；现在”AI 辅助分析让把补丁 diff 或公告变成可用 exploit 更便宜”，于是更多行为体能在技术细节公开后数小时甚至数分钟内行动。影响：面向公网的关键漏洞，7 天或 30 天的修复 SLA 建立在一个已经不存在的延迟假设上。

4. 修复成本是非线性的，而且落在最没钱的一方。 发现端一人一周，修复端四人两月加 390 个文件，最后埋单的是没有明确收入的 PHP 基金会。IEEE 文章里哥伦比亚大学的 Suman Jana 把这叫”发现与修复的根本不对称”：找洞只要找到一个入口，修洞要证明所有攻击路径都关上了、且没弄坏任何现有功能。影响：开源基础设施的安全预算，会持续被 AI 放大后的发现速度拖着走，而不是被它解放。

5. 这次是”提前发现”，不是”侥幸无事”。 漏洞在 2024 年就曾以”只是崩溃”的形式报给 PHP 基金会，没人当回事；真正把它变成 RCE 的是今年 Calif 的独立审计（由 OpenAI 赞助）加上 AI 工具。影响：你仓库里那些”只是偶发崩溃”的 issue，现在应该被重新归类为待评估的安全债，而不是稳定性噪音。

工程师/产品人今天能做什么

1. 先分清”应用”和”运行时”。 更新 WordPress、Drupal、Composer 依赖都不会更新底下的 PHP。检查所有容器基础镜像、托管面板、遗留 vhost 的 php -v，对照 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12。升级后要重启 Apache、PHP-FPM 和所有常驻 worker，否则旧进程仍带着旧代码。

2. 升不了的，按官方顺序做临时缓解，别自创。 第一位是在网关或 WAF 层阻断/限制 multipart/form-data 上传，并限制 part 数量与每个 part 的 header 数；其次是监控请求体里出现 PHP_SESSION_UPLOAD_PROGRESS 的 POST；session.upload_progress.enabled = 0 只针对 CVE-2026-109619 的 session 生命周期路径，不是万能药，关闭前要确认没有应用依赖它。

3. 把关键漏洞的处置窗口改成小时。 挑一个公网服务，演练一次”补丁发布 → 灰度 → 全量”能否在 4 小时内完成；如果卡在变更审批上，那才是真正要修的东西。

4. 日志回溯起点改到 10 月 17 日。 找异常 multipart 请求紧跟着 memory-limit 报错、成片的 HTTP 500、异常大的响应 Cookie、以及无法解释的 PHP worker 重启。注意这组漏洞运行在应用层之下，应用日志可能几乎没有痕迹，得看 FPM/Apache 与系统层。

5. 把语言运行时写进资产清单。 你的 SBOM 里如果只有 composer.lock，就等于没有这份清单——这次 70% 的暴露面来自一个所有 CMS 共享的、平时没人看的依赖。

待观察

• 是否真的”无人失陷”尚无定论。 IEEE 写的是”就目前所知灾难被避免了”，而 AWS 明确说在披露前就观测到利用尝试、且”PHP2Shell 现在正被广泛尝试利用”。尝试与成功入侵是两件事，目前没有公开证据表明有大规模成功攻陷，但也没有反证。
• 绕过补丁的 PoC 是否成立。 php2shell.com 承认 GitHub 和 X 上流传的 PoC 引发了”补丁可被绕过”的疑问，其条件是需要不常见的配置组合（应用运行时修改 serialize handler，且开启 session upload progress）。PHP 建议在下一个常规 bugfix 版本前先设 session.upload_progress.enabled = 0。
• 泄露与 embargo 破裂的调查。 10 月 20 日匿名帖与工具截图先于公告流出，PHP 因此把发布提前了一天。谁提前放出了材料、以及同一种”AI 扫旧代码”的方法会不会在别的语言运行时里复制出下一个 PHP2Shell，是接下来几个月更值得盯的线索。