摘要

2026 年 8 月 19 日，Wiz Research 的安全研究员借助 Wiz Atlas 平台，配合 Gemini 4 Argon 与 GPT-5.6 Sol 两个模型，在 PHP 解释器内核里找到了一条完整可利用的预认证远程代码执行链。PHP 官方于 10 月 21 日发布修复版本，两个漏洞被分配为 CVE-2026-109618 与 CVE-2026-109619，CVSS 评分均为 9.2。

这件事的特殊之处不在漏洞本身，而在于它的产生方式:过去需要一个世界级研究团队投入数月才能完成的引擎级漏洞挖掘，这次由一名研究员带着 AI 智能体在一周内完成。影响面同样惊人——从 PHP 5.4 起的几乎所有版本都受影响，而按 Wiz 的统计口径，全球约 70% 的网站运行在 PHP 之上，包括 WordPress、Drupal、Joomla 和 MediaWiki 这些占据内容管理系统主流的项目。

更值得警惕的是漏洞的位置:它不在某个插件、某个模板、某个业务代码里，而在 PHP 引擎本身。这意味着上层应用的补丁节奏、WAF 规则和代码审计都难以覆盖，唯一有效的处置方式是升级 PHP 运行时。本文将拆解这条漏洞链的技术细节、AI 在其中扮演的角色，以及它对 Web 基础设施安全意味着什么。

事件背景

PHP 是 Web 世界最沉默的基础设施。它不像前端框架那样频繁出现在技术新闻里，但 WordPress、Drupal、Joomla、MediaWiki、Laravel、Symfony 都跑在它上面。一个引擎级的内存破坏漏洞，等于同时把数百万个站点的门锁换成了同一把劣质锁。

Wiz Research 的这次研究发生在 2026 年 8 月中旬。团队没有从应用层代码入手，而是直接把目标对准 PHP 解释器的两个内部机制:上传进度处理（upload progress）和致命错误回溯（fatal error backtrace）。这两处逻辑都涉及复杂的对象生命周期管理，长期被研究者视为"高噪声、低产出"的区域——手工审计成本极高，历史上公开的成果寥寥。

研究在 8 月 19 日完成，随后进入协调披露流程。10 月 21 日，PHP 发布安全补丁；同一天，Wiz 公开技术细节。这个时间差说明厂商响应并不慢，真正的问题是生态的升级速度:大量生产环境仍停留在早已停止维护的 PHP 分支上。

同期还有一条容易被忽略的线索:OpenAI 也披露了一批由 AI 辅助发现的 Node.js Brotli 相关漏洞，修复版本为 22.23.4、24.22.1 和 26.12.1。Cloudflare CEO Matthew Prince 对此的公开回应是，公司已经"习惯了大量打补丁"。两件事放在一起看，指向同一个趋势——AI 正在把漏洞发现的产能提升一个数量级，而修补侧的产能并没有同步提升。

核心技术解析

技术架构

PHP2Shell 不是单个漏洞，而是一条由两个独立缺陷串联而成的利用链。它之所以被称为"引擎级"，是因为攻击面位于 PHP 运行时内部，与具体应用无关。

第一个缺陷出现在上传进度（upload progress）机制的反序列化路径上。PHP 在处理上传进度时会对会话中的进度数据进行反序列化，而这个过程中存在释放后使用（use-after-free）问题，同时伴随一处可以远程读取进程内存的信息泄露。信息泄露在这里至关重要:它让攻击者能够拿到堆地址和关键指针，从而绕过现代 PHP 版本上的地址随机化保护。

第二个缺陷位于致命错误回溯路径。当 PHP 在处理致命错误并生成 backtrace 时，同样存在释放后使用问题；结合 OPcache 的类型混淆（type confusion），攻击者可以把已经被释放的对象重新占位，最终把控制流转到可控位置。

把两者串起来，攻击路径非常清晰:先利用信息泄露拿到内存布局，再触发释放后使用并完成对象替换，最后通过 OPcache 的类型混淆实现任意代码执行。整个过程不需要任何有效凭据。

  graph TD
    A[攻击者发送构造请求] --> B[触发 upload-progress 反序列化路径]
    B --> C[CVE-2026-109618: use-after-free]
    C --> D[远程读取进程内存,泄露堆地址与指针]
    D --> E[绕过 ASLR / 地址随机化]
    E --> F[触发 fatal-error backtrace 路径]
    F --> G[CVE-2026-109619: use-after-free]
    G --> H[OPcache 类型混淆完成对象替换]
    H --> I[控制流劫持]
    I --> J[预认证远程代码执行]
    J --> K[读取 worker 内存中的密码 / Token / API Key]

关键创新点

第一，AI 承担了"广度搜索"而不是"最终判断"。 Wiz 的做法不是让模型直接输出 exploit，而是让智能体在巨大的代码空间中做假设生成、路径枚举和最小化验证。Wiz Atlas 负责把代码库、运行时行为和已有研究组织成可检索的结构，模型负责提出"这里可能有问题"的候选点。人类研究员的价值仍然在最后一步:判断哪条路径真的可被利用。

第二，把两个弱信号拼成强攻击链。 单独看，信息泄露和释放后使用都可能被评为"需要本地条件"或"利用难度高"。AI 的优势在于它不会因为单个缺陷"看起来不够严重"就放弃，而是持续在同一进程上下文中寻找可组合性。最终形成的链条把两个中等信号升级为 CVSS 9.2 的预认证 RCE。

第三，目标选择从"应用"上移到"运行时"。 这次研究没有去扫某个 CMS 的插件市场，而是直接锁定 PHP 引擎。这个选择本身就带有战略意味:引擎级漏洞的影响面按"所有运行该运行时的站点"计算，而不是按"某个插件的安装量"计算。

第四，验证是在真实容器里完成的。 团队对 wordpress:latest、drupal:latest、joomla:latest 等官方镜像直接演示了预认证 RCE，而不是停留在 PoC 层面的理论推演。这意味着漏洞与具体 CMS 版本无关，只要 PHP 版本落在受影响区间，攻击面就存在。

性能评测

这里没有传统意义上的 benchmark，但有几个数字值得记录:

CVE-2026-109618 与 CVE-2026-109619 的 CVSS 均为 9.2。按 Wiz 的估算，全球约 70% 的网站运行在 PHP 上，受影响的 CMS 覆盖 WordPress、Drupal、Joomla 和 MediaWiki。这个比例意味着，漏洞披露后的几周内，互联网上会出现大量未修补的暴露面。

利用效果上，攻击者可以在未认证状态下取得代码执行权限，并且能从 PHP-FPM worker 的内存中读出密码、会话 Token 和第三方 API Key。Wiz 演示了通过 PHPSESSID cookie 把读取到的内容回显出来的手法——这意味着攻击者不需要交互式 shell，一个 HTTP 响应就足以完成凭据窃取。

行业影响

对市场的影响

对托管服务商和云厂商来说，这是一次典型的"底层依赖清算"。客户买的是 WordPress 建站服务，真正出问题的是 PHP 运行时；补丁要不要打、什么时候打、打完会不会破坏兼容性，全部压在服务商身上。历史上 PHP 大版本升级的主要阻力就是兼容性，而这次漏洞要求的是"必须升级"，没有回旋余地。

对安全产业而言，AI 辅助漏洞挖掘从"演示"进入了"产出关键基础设施 0day"的阶段。这会直接改变漏洞赏金、渗透测试和红队服务的定价逻辑:当发现成本下降一个数量级，靠信息不对称收费的空间会被压缩，价值会向"验证、利用链构造、修复验证"这些仍然依赖人类判断的环节转移。

对开发者的意义

对普通开发者来说，最直接的动作只有一个:确认 PHP 版本并升级。具体包括检查容器基础镜像、CI 中的运行时版本、以及那些"能跑就不动"的历史项目。由于漏洞位于引擎层，应用层的输入过滤、WAF 规则和框架中间件都无法提供实质防护。

对安全团队来说，这次事件提供了一个新的评估维度:资产清单里不能只记录"用了哪个 CMS"，还要记录"跑在哪个运行时版本上"。很多团队能做插件的版本管理，却对 PHP 小版本一知半解，而后者才是这次真正的风险载体。

商业化前景

短期看，围绕"AI 找洞"的创业公司会明显增多，Wiz 这类平台会把"AI 原生漏洞研究"作为核心卖点。中期看，防守侧的机会更大:自动化补丁编排、运行时版本治理、以及针对"AI 批量产出的漏洞"的优先级排序，都会成为刚需。

一个不太乐观但必须承认的现实是，漏洞发现速度提升之后，攻击者的窗口期并没有变短，而是变得"更拥挤"。防守方要面对的不再是每年几个高危漏洞，而是持续不断的中高危洪流。

实际体验

以下场景基于 Wiz 公开的技术报告、PHP 官方公告与容器环境复现视角整理，不代表笔者对生产系统的直接测试。

场景一:容器镜像排查。 对一个典型的自建站点做检查，第一步是确认基础镜像的 PHP 版本。很多 wordpress:latest 镜像在构建时就锁定了某个 PHP 小版本，如果构建缓存没有刷新，实际运行的可能是几个月前的运行时。这类问题无法靠"重新部署应用代码"解决，必须重建镜像。

场景二:应急响应中的凭据轮换。 假设漏洞已被利用，攻击者能读到 worker 内存中的密码、Token 和 API Key。此时仅升级 PHP 是不够的，必须把所有可能进入过进程内存的凭据全部轮换，包括数据库密码、对象存储密钥、第三方支付和短信服务凭据。Wiz 演示的 PHPSESSID 回显手法说明，攻击者甚至不需要留下明显的 shell 痕迹。

场景三:WAF 的边界。 很多团队的直觉是"加一条 WAF 规则"。但这次攻击的入口是合法的 HTTP 上传请求与错误触发路径，payload 在协议层面并不异常，规则误报率和绕过成本都很高。真正有效的缓解只能来自运行时升级，或者在上游做虚拟补丁。

  sequenceDiagram
    participant A as 攻击者
    participant W as Web 服务器 / PHP-FPM
    participant P as PHP 引擎
    participant M as Worker 进程内存
    A->>W: 构造 upload-progress 请求
    W->>P: 进入反序列化路径
    P->>P: 触发 use-after-free 并泄露堆地址
    P-->>A: 通过响应回显内存片段
    A->>W: 触发致命错误回溯
    W->>P: 进入 backtrace 路径
    P->>P: OPcache 类型混淆，控制流劫持
    P->>M: 读取密码 / Token / API Key
    P-->>A: 通过 PHPSESSID 回显窃取结果

优势与不足

优势:

• 攻击链完整，从信息泄露到代码执行闭环，且无需任何凭据。
• 影响面覆盖 PHP 5.4 以来的几乎所有版本，与上层 CMS 无关。
• 在官方容器镜像上可直接复现，说明现实可利用性很高。
• AI 把引擎级漏洞的发现周期从数月压缩到一周，方法论可复用。
• Wiz 选择协调披露并同步公开技术细节，给了生态修复窗口。

不足:

• 披露到大规模修补之间存在明显时间差，长尾站点的风险会持续很久。
• 引擎级漏洞的修复意味着运行时升级，兼容性回归测试成本高。
• AI 辅助挖掘的结论仍需人类验证，“模型说有问题"不能直接当作漏洞报告。
• 这类研究同时降低了攻击方的门槛，防御方需要重新评估威胁模型。
• 公开细节虽然有助于防守，但也缩短了未修补系统的安全窗口。

总结与展望

PHP2Shell 的重要性有两层。表层是一组高危漏洞:CVSS 9.2、预认证 RCE、影响约 70% 的网站、位于引擎层难以用应用侧手段缓解。深层则是一个信号:AI 已经能够在真实的基础设施代码里，稳定产出过去只有顶尖人类团队才能发现的高质量漏洞。

接下来值得关注三件事。第一，PHP 生态的升级率会在未来几个月成为可观测指标，长尾站点的暴露情况会决定这次事件的真实破坏力。第二，AI 辅助漏洞研究需要一套披露与质量控制规范，否则"批量产出的中低质量报告"会淹没厂商的安全响应团队。第三，防守侧必须把"运行时版本治理"提升到和"依赖漏洞扫描"同等的优先级。

对开发者来说，这次事件最实用的结论非常朴素:去查一下你的 PHP 版本，然后升级它。对行业来说，更值得记住的是那句话——漏洞发现的经济学已经改变，而修补的经济学还没有。

参考来源:

• PHP2Shell: Anatomy of a Pre-Auth RCE in PHP
• Coordinated disclosure of critical vulnerabilities
• PHP 8.x 安全修复公告（2026-10-21）