PHP2Shell 的真正信号:当 AI 把补丁到武器的窗口压到小时级,你的更新 SLA 已经失效了

TL;DR：2026-10-17，AWS MadPot 蜜罐在野外捕获了一次针对 PHP 引擎的零日利用——比补丁公开早了整整 4 天。CVE-2026-109618 / CVE-2026-109619 影响 PHP 5.4 以来的所有版本，Wiz 在 WordPress、Drupal、Joomla 默认容器上演示了无需认证的远程代码执行。但本文不重复「快打补丁」。真正需要重新校准的是：当 AI 辅助分析让 patch diff 转 weaponized exploit 的成本大幅下降时，7 天甚至 30 天的软件更新 SLA 假设了一个不再存在的延迟。

1. 时间线：4 天的信息差

2026-08-19，Wiz Research 使用 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol 发现了第一个 PHP 漏洞。第二天，他们在 Drupal 上确认了无需认证的远程代码执行；再一天，WordPress 也沦陷。08-24，报告提交给 PHP 安全团队。09-21，PHP 确认并开始开发协调修复方案。（来源：Wiz Blog "Responsible disclosure timeline"，2026-10-21）

与此同时，另一条线索在独立推进。Calif 的研究员 Ryan Austin（@lcfr_hax）在 OpenAI Patch the Planet 项目中于 07-30 开始审计 PHP，08-01 就找到了第一个 OOM-fatal 路径，08-11 正式报告 PHP，08-14 共享了 RCE PoC。（来源：Calif 技术稿 "An interesting timeline of events"，2026-10-21）

两个团队的工作汇聚成一个 embargo 期内的协调披露计划。PHP 基金会、OpenAI、Calif、Wiz 以及 Cloudflare、AWS、Automattic、Fastly、Akamai 等基础设施厂商同步准备缓解措施。（来源：Wiz Blog "Industry-level collaborations" + Cloudflare Blog，2026-10-21）

2026-10-17，AWS 威胁情报系统 MadPot 捕获了一次 PHP2Shell 利用尝试。源 IP 103[.]216[.]220[.]92 关联到一个商业匿名网络。此时距离补丁发布还有 4 天，距离 embargo 解除还有 4 天。AWS CISO CJ Moses 在博客中写道："it remains unclear how the actor acquired exploit information prior to disclosure."（来源：AWS Security Blog，2026-10-21）

10-20，PHP 安全团队发出预告：次日 14:00 UTC 发布修复两个 CVSS v4 9.2 关键漏洞的版本，并声明"保留在细节公开或利用出现时提前发布的权利"。（来源：PHP News Archive "Upcoming Critical PHP Security Release"，2026-10-20）

这个预告本身成了泄压阀的一部分。据 Daubois 复盘，embargo 在同一天从多个口子同时失守：一篇匿名 Hacker News 帖子发布后被删除，但截图已经流到 X 和 Mastodon；一张标注来自 Calif 的 PHP2Shell 工具截图连同一小段利用视频先后流出又被删除；watchTowr 公开确认漏洞真实存在并贴出了两个 CVE 编号。PHP 随后加快了发布节奏——实际补丁在 13:30 UTC 左右已经可见，比原定 14:00 略早（Berardinelli 观测值）。（来源：daubois[.]dev，2026-10-21；berardinellidaniele[.]com，2026-10-22）

武器化的时间线并不在补丁之后，而在补丁之前。AWS 记录到最早的公开 PoC 出现在 10-21 凌晨约 02:00 UTC；02:00 到 08:00 UTC 之间，MadPot 又记录到来自多个不同匿名基础设施的利用尝试，payload 各不相同——不是同一个人在扫描，而是多个 actor 在独立行动。也就是说，在 14:00 的 embargo 正式解除之前，针对这批漏洞的投送已经跑了 6 到 12 个小时。等到补丁真正上线，新的 PoC 在数小时内出现，并几乎立刻被用来打传感器。Moses 的原话是："PHP2Shell is now seeing broad exploitation attempts in the wild."（来源：AWS Security Blog，2026-10-21）

2. 漏洞本质：引擎层，不是应用层

多数报道把 PHP2Shell 描述为「PHP 内存管理漏洞」，这个说法不够精确。它不是某个 CMS 插件的 bug，也不是某个 Web 应用的输入校验缺失——它是 PHP 引擎本身（ZendMM 分配器和请求生命周期管理）的结构性缺陷。

CVE-2026-109618：OOM 导致的未初始化状态消费。 PHP 在处理 multipart POST 请求时，如果 memory_limit 被触发，引擎会通过 longjmp() 跳出当前上下文。问题在于，某些内部数据结构（如 HashTable 的 Bucket）在分配过程中被打断后处于半初始化状态，而请求 shutdown 流程仍然会去遍历并释放这些结构。Calif 的复现给出了具体位置：_zend_hash_str_add_or_update_i 先自增 nNumUsed 和 nNumOfElements，再分配 key——如果 key 分配 fatal，count 已经加了，teardown 于是把未初始化的桶当成活对象处理。攻击者可以通过精心构造的 multipart 请求（大量嵌套字段名、空文件控件、无 Content-Length 的 chunked 传输）在不超出 post_max_size 的前提下精确触发 OOM，让 shutdown 消费到受控的脏数据。Apache mod_php 因为即使 startup 失败也会调用 php_request_shutdown()，成为最直接的利用目标。（来源：PHP GHSA-w8hw-w9fx-j79w + Calif 技术稿代码段，2026-10-21）

CVE-2026-109619：fatal error 后的悬垂全局指针。 PHP worker 进程跨请求复用。某些全局状态（如 Session upload progress 数据、PHP 8.5 的 EG(last_fatal_error_backtrace)）指向当前请求堆上的内存。如果 fatal error 中断了正常的清理流程，这些指针不会被重置。当下一个请求到达同一个 worker 时，在正常初始化完成之前，早期运行的代码（如 INI 诊断或 Session upload progress 处理）就会读取到已释放的内存。这是一个经典的跨请求 use-after-free。（来源：PHP GHSA-6wmf-4rv5-p3rp，2026-10-21）

两个 CVE 的共同点：利用发生在应用代码运行之前。你不需要 WordPress 有漏洞，不需要 Drupal 配置错误，甚至不需要跑任何框架。只要 PHP 版本在受影响范围内，一个 Hello World 脚本就可能被拿下。（来源：Wiz Blog "Impact"，2026-10-21）

这里需要纠正几个广泛传播的错误信息。PHP 安全团队成员 Alexandre Daubois 指出：第一，CVSS v4 评分是 9.2，不是社交媒体上流传的 10.0；第二，session.upload_progress.enabled = Off 只缓解 CVE-2026-109619 的 Session 路径，对 CVE-2026-109618 无效，官方首要的临时缓解措施是设置 memory_limit=-1（针对 109618），且不应使用 RLIMIT_AS 或 RLIMIT_DATA，因为这会导致 mmap() 失败从而触发同一条漏洞路径。（来源：daubois[.]dev，2026-10-21；PHP 安全公告，2026-10-21）

还有一个在中文圈流传的说法：「多国政府网站连夜下线」。核查 PHP、Cloudflare、AWS、Wiz、Calif 五方公开声明，均无此表述，也没有可信出处，本文不予采用。

3. AI 拐点：从理论缺陷到实战武器的成本坍塌

这段代码在 PHP 里躺了超过十年。Wiz 的原话是："The underlying flaws had been present for decades, but demonstrating their exploitability required an exceptionally complex chain of steps, at the edge of what human researchers could practically achieve."（来源：Wiz Blog "Overview"，2026-10-21）

改变这个等式的是 AI。

Wiz 使用了三个模型：Wiz Atlas、Gemini 4 Argon、GPT-5.6 Sol。其中 Gemini 4 Argon 在漏洞发现、exploit 开发、攻击检测和补丁验证四个环节都做出了关键贡献。Google DeepMind 的 Gemini Security 负责人 Raluca Ada Popa 评价说："frontier AI is a game-changer for cyber defense."（来源：Wiz Blog "The AI inflection point"，2026-10-21）

Calif 的方法更直接。Ryan Austin 用 LLM 把 Stefan Esser 2004 年发现的原始 memory-limit RCE 模式泛化为一个可搜索的结构化 pattern——"publish state → fallible work → initialize/commit → nonlocal fatal during fallible work → commit skipped → surviving consumer trusts false state"。这个 pattern 不仅复现了 _zend_hash_str_add_or_update_i 中的已知缺陷，还自动找到了 Session upload progress 路径中的第二个变体。（来源：Calif 技术稿 "How did we find this?"，2026-10-21）

CJ Moses 在 AWS 博客里给出了更宏观的判断："AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit. As a result, more actors can act within hours or even minutes once technical details of a vulnerability are disclosed."（来源：AWS Security Blog，2026-10-21）

注意他的措辞是 "cheaper"，不是某些中文报道翻译的「趋近于零」。但方向是一致的：过去，只有少数顶级团队能完成从 patch diff 到 weaponized exploit 的转化，其他人等着他们发布 PoC。现在，这个依赖关系正在瓦解。Wiz 的结论更直白："a single researcher completed in a week what previously would have taken a world-class team months of work."（来源：Wiz Blog "Conclusion"，2026-10-21）

这不是一个 PHP 的故事。这是所有软件供应链的信号：当 exploit 开发的边际成本被 AI 压低时，复杂度不再是屏障。

4. Coordinated Disclosure 的结构性裂缝

Coordinated disclosure（协调披露）的核心假设是：embargo 期内只有受信方知道漏洞细节，防御者利用这段时间准备补丁和缓解措施，公众在补丁就绪后才获得信息。

MadPot 在 10-17 的捕获打破了这个假设。一个不在协调名单上的 actor，通过未知渠道获得了 exploit 能力，并在 embargo 解除前 4 天就开始投送 payload。Moses 明确说："An embargo protects defenders only until someone else finds the same bug."（来源：AWS Security Blog，2026-10-21）

更深层的变化是 patch-to-exploit 窗口的压缩。过去的安全运营模型假设：补丁发布后，攻击者需要数天到数周来逆向工程并开发稳定 exploit。这个延迟是 7 天甚至 30 天更新 SLA 的基础。PHP2Shell 把这个假设打穿了：利用尝试在 embargo 解除前就已在跑，补丁公开后数小时内新 PoC 即出现并立刻用于打击传感器。Corelight 的安全研究员 Ben Reardon 在 embargo 期间就开发完了 Zeek 与 Suricata 检测规则，并在披露当天同步开源——防守方在用 AI 加速检测，攻击方也在用同样的工具加速利用。（来源：AWS Security Blog + Corelight Blog，2026-10-21）

安全分析师 Daniele Berardinelli 提供了必要的冷静视角。他指出，目前公开的 PoC 大多是「slop」——由不理解底层机制的人用 AI 生成的不可靠代码。真正的通用一键 RCE 还不存在，因为 exploit 需要精确匹配目标的 ASLR 布局、PHP 构建版本、SAPI 类型和扩展加载情况。Wiz 自己也承认，从一个部署迁移到另一个部署需要反复测试和调试。但这恰恰印证了 Moses 的论点：AI 降低的不是单次利用的难度，而是适配新目标的边际成本。（来源：berardinellidaniele[.]com，2026-10-22；Wiz Blog "The AI inflection point"，2026-10-21）

对于安全运营团队，这意味着两件事必须改变：第一，调查起点不能是披露日，而应是已知最早利用日（对 PHP2Shell 而言至少回溯到 10-17）；第二，面向互联网的关键系统，缓解时间应以小时而非天来度量。（来源：AWS Security Blog，2026-10-21）

5. 缓解现实：没有银弹，只有分层

唯一完整的修复是升级。 PHP 8.5.12、8.4.27、8.3.36、8.2.35 已在 10-21 发布。PHP 8.1 及更早版本不再接收上游更新，但安全团队为 7.4、8.0、8.1 提供了最小源码 backport 分支。如果你的发行版或 LTS 供应商已推送补丁，立即安装。（来源：PHP News Archive，2026-10-21）

如果不能立即升级，以下是临时措施及其局限：

（来源：PHP 安全公告 + daubois[.]dev + Cloudflare Blog + Corelight Blog，2026-10-21/22）

关于 IOC 的警告：AWS 公布的 6 个 IP 地址（如 103[.]216[.]220[.]92、31[.]223[.]184[.]166 等）关联的是共享匿名基础设施，Moses 明确建议"investigate any observations involving these addresses as opposed to blocking"。不要直接加入封禁列表。（来源：AWS Security Blog "Indicators of Compromise"，2026-10-21）

6. 结论：SLA 需要重新校准

PHP2Shell 的影响面足够大——PHP 驱动着全球约 70% 的网站，包括 WordPress、Drupal、MediaWiki（Wikipedia）、Magento、Laravel、Symfony 的底层运行时。但它留下的最重要遗产不是一个 CVE 编号，而是一个关于时间的信号。

当 AI 把一个隐藏十年的引擎级缺陷在数小时内变成可用武器时，传统的 7 天 / 30 天补丁窗口假设了一个不再存在的缓冲期。CJ Moses 的建议应该被写进每个安全团队的运维手册："For critical vulnerabilities in internet-facing systems, measure patch and mitigation timelines in hours."（来源：AWS Security Blog，2026-10-21）

Coordinated disclosure 仍然是正确的模型，但它的保护效力取决于一个越来越脆弱的假设：没有人会在 embargo 期内独立发现同一个 bug。MadPot 的数据告诉我们，这个假设已经不能用来做安全规划了。