Wiz 研究团队（Wiz Research）在核心 PHP 中发现多个严重漏洞。PHP 支撑着全球 70% 的网站，也是 WordPress、Joomla、Drupal 和维基百科（Wikipedia）的 MediaWiki 的基础。这些漏洞包括内存泄露与无需认证的远程代码执行，存在于 PHP 自身，独立于上层应用，让所有受影响网站立即面临风险；过去十年发布的每个 PHP 版本至少受其中之一影响，且受影响版本最早可追溯到 5.4 版。2026 年 10 月 21 日，PHP 发布补丁修复核心引擎的多个内存安全漏洞。

执行摘要

• Wiz Research 在核心 PHP 中发现了多个严重漏洞。PHP 是为全球 70% 网站提供支持的常用通用脚本语言。成功利用这些漏洞可让攻击者控制受影响的服务器、窃取敏感数据，并篡改运行其上的网站。
• PHP 是网络的支柱，支撑着 WordPress、Joomla、Drupal、维基百科的 MediaWiki 等众多系统。
• 这些漏洞包括内存泄露和未认证远程代码执行（RCE），存在于 PHP 本身，与上层运行的应用无关，使所有受影响的网站面临即时风险。
• 过去十年发布的每个 PHP 版本都至少受其中一个漏洞影响，最早可追溯到 5.4 版。攻击者可以远程利用，某些情况下相当容易。强烈建议立即修补。
• 2026 年 10 月 21 日，PHP 发布了补丁，修复了核心引擎中的多个内存安全漏洞。
• 这些发现堪称 PHP 乃至软件史上最严重的漏洞之列。底层缺陷已存在数十年，但要证明其可利用性，需要极其复杂的步骤链，几乎达到人类研究人员实际能完成的极限。前沿 AI 模型大幅降低了这一门槛，把一个长期存在的缺陷变成了可用漏洞。

概述

我们在此说明前沿 AI 如何帮助我们发现并修复隐藏在 PHP 代码库中十多年的漏洞。下述问题都源于一些关键架构决策，其中部分决策早在十多年前做出；它们被归入两个 CVE，严重程度达到 CVSS 9.2。这项工作后来发展成跨行业协作，以保护客户、查找变种、部署检测和缓解措施，并在协调披露前验证补丁。

几乎所有 PHP 版本都至少受其中一个问题影响，包括可追溯到 PHP 5.4 的发布版本。这些漏洞可让未认证攻击者在受影响的服务器上执行代码，或读取敏感的进程内存。这些内存可能包含属于其他请求或服务器本身的密码、认证令牌、API 密钥和证书。

PHP 是支撑大量网络的编程语言，为 WordPress、Drupal 和运行维基百科的 MediaWiki 提供动力。其核心引擎中的缺陷可能影响整个生态系统中的网站，即使这些网站自己的应用代码是安全的。

一些漏洞之所以成为转折点，是因为它们挑战了关于安全的基本假设。2014 年，Heartbleed 暴露了保护互联网共享基础设施的脆弱性。2021 年，Log4Shell 揭示了深度嵌入的软件依赖如何造成广泛暴露，而组织难以识别这些依赖。我们认为 PHP2Shell 可能标志着 AI 时代的类似转折点，说明 AI 如何改变长期存在漏洞的实际可利用性。构建该漏洞利用需要串联多个缺陷，并通过反复测试和调试适应每个目标的内存布局。前沿模型对让这一过程变得可行至关重要，使我们能在数小时内跨多个应用开发和调整可用的漏洞利用。随着这项工作所需的时间和专业知识减少，复杂性可能不再提供有意义的障碍，从而改变我们对“实际可利用”的定义。

Wiz Research 感谢 PHP 团队、Calif 和 OpenAI 在发现、协调和补丁验证方面的工作。OpenAI 和 Calif 也发布了包含漏洞历史、技术细节和披露过程见解的博客，PHP 同样发布了公告。

漏洞

所有已披露的漏洞都是内存安全问题，源于 PHP 在处理请求时处理致命错误（尤其是内存不足错误）的方式中的缺陷。这些缺陷会在请求意外结束后留下损坏的 PHP 内部状态。后续的请求或 worker 可能重用这一陈旧状态，导致内存泄露或损坏。

下表展示了我们向 PHP 报告的每个漏洞所演示的影响类型。表中列出的应用是我们为演示 RCE 选择的目标，属于代表性目标——由于易受攻击的代码位于 PHP 本身，利用这些漏洞并不需要这些 CMS。

| 跟踪 ID | 漏洞 | 攻击者能实现什么 | 我们演示了什么 | | --- | --- | --- | --- | | CVE-2026-109618 | 上传进度反序列化器释放后使用；远程进程内存泄露 | 破坏进程内存并执行代码；未认证泄露 PHP worker 内存 | WordPress、Drupal 和 Joomla 上的预认证 RCE；与应用无关的远程内存泄露 | | CVE-2026-109619 | 致命错误回溯释放后使用；OPcache 类型混淆 | 破坏进程内存并执行代码；破坏共享 PHP 状态并执行代码 | Drupal 上的预认证 RCE；WordPress 上的预认证 RCE |

我们只涵盖遵循这一危险模式的四个可利用漏洞实例（归入两个 CVE），但 PHP 代码库中还存在其他已跟踪、且可能未跟踪的该问题变种。这些变种有不同的利用条件，并可能导致不同类型的影响。无论如何，PHP 团队提供的补丁从核心修复了该问题，并在已修补版本中消除了所有变种。

影响

我们将这些漏洞组合成一个名为 php2shell 的单一漏洞利用脚本，并演示它可在测试时使用的最新容器镜像上，对 WordPress（wordpress:latest）、Drupal（drupal:latest）和 Joomla（joomla:latest）的部署无需认证地远程执行代码。

这些平台说明了影响范围，但漏洞位于 PHP 本身。利用并不依赖应用代码中的缺陷：即使在受影响 PHP 版本上运行的简单“Hello World”应用也可能易受攻击。

此外，我们还演示了攻击者无需实现远程代码执行，就能从 PHP 进程内存中读取敏感数据，包括密码、令牌和 API 密钥。

AI 拐点

易受攻击的代码已存在十多年。要将这些缺陷变成可用的漏洞利用，需要串联多个漏洞，并考虑 PHP 在请求之间如何分配和重用内存。内存漏洞极其复杂；PHP 版本、配置和应用行为的差异会破坏漏洞利用所依赖的假设。针对一种部署有效的攻击，可能需要大量调整才能针对另一种部署生效，每次调整都需要进一步分析、测试和调试。在前 AI 时代，这种人工工作难以实现，更难以规模化。

有了 AI，这不再是障碍。大语言模型（LLM）能帮助调整漏洞利用，以适应不同的 PHP 版本、配置和内存布局。借助测试和调试工具，模型可以分析失败并迭代调整，减少针对每个目标所需的专业工作量。这大幅降低了跨不同部署规模化攻击的门槛。

这改变了发现和攻击的成本结构。随着 AI 降低开发和调整复杂漏洞利用所需的工作量，那些曾经看似不切实际、难以利用的漏洞也成为可行目标。

我们在整个研究过程中使用了 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol。其中，Gemini 4 Argon 在发现漏洞、开发漏洞利用、攻击检测以及验证补丁方面做出了极其宝贵的贡献。

“借助 Gemini 4 Argon，Wiz 团队展示了前沿 AI 为何是网络安全防御的游戏规则改变者。十多年来，这些严重漏洞一直未得到处理，因为漏洞发现和利用极其复杂。我们很高兴看到 Gemini 4 Argon 帮助防御者弥补这一差距，发现漏洞并协助修补它们。”

Raluca Ada Popa，Google DeepMind 的 Gemini Security 负责人

行业级协作

在公开披露之前，Wiz Research 与 PHP 团队、Calif 和 OpenAI 合作，进行发现、协调和补丁验证。我们还与 Google Cloud、Cloudflare、AWS、Microsoft、Automattic、Fastly、Akamai、Imperva、Vercel 以及许多其他伙伴合作，为无法立即更新的组织准备客户指南、检测方法和开箱即用的缓解措施。

核心 PHP 中的漏洞远超单个应用的影响范围。PHP 运行在各种云、托管提供商、内容分发网络（CDN）以及数百万台独立管理的服务器上。在技术细节公开之前减少暴露，需要整个生态系统的协调工作。

技术深入分析

漏洞：上传进度反序列化器释放后使用

PHP 的 Session 模块可以在同一预初始化窗口内，于上传进度处理期间解码会话数据。解码器将属于该请求的簿记信息存储在 BG(unserialize) 中。致命的分配失败会中断这一路径，销毁请求堆，并使反序列化器的全局状态保持已发布状态。

在同一 worker 处理后续请求时，PHP 可能把攻击者重新占用的内存当作活跃的反序列化器簿记信息来使用。这一陈旧状态变成了强大的内存损坏原语。我们将其与内存泄露结合，消除了地址不确定性，并在 WordPress、Drupal 和 Joomla 上实现了未认证远程代码执行。

WordPress、Drupal 和 Joomla 的利用链是代表性演示。底层原语存在于 PHP 引擎层面，可影响在易受攻击版本上运行的任何 PHP 应用。

这些问题发生在应用层之下，因此应用日志可能几乎没有上下文。在打补丁之前，防御者应特别关注：异常的 multipart 请求后伴随内存限制错误或重复的 HTTP 500 响应、异常巨大或畸形的 PHPSESSID 响应 Cookie，以及无法解释的 PHP worker 频繁重启。这些信号可以指导调查。应用 PHP 安全更新仍是唯一完整的修复措施。

漏洞：远程进程内存泄露

PHP 在请求启动期间、正常模块初始化完成之前解析 RFC1867 multipart 请求。会话上传进度处理可以在此早期阶段初始化 Session 状态，并在 PS(id) 中发布会话 ID。内存不足错误会在清理完成之前中止请求。随后 PHP 销毁请求堆，并可能使 PS(id) 指向已释放的分配内存。

同一 worker 处理的后续 multipart 请求，可能在正常 Session 初始化重置该指针之前，进入上传进度清理路径。PHP 将这一陈旧指针和长度当作活跃的 zendstring 来信任，并把被重新占用的堆内容 URL 编码进 PHPSESSID 响应 Cookie。即使应用从未调用 sessionstart()，该攻击仍然有效，因此该问题与应用无关。我们演示了未认证泄露活跃 worker 内存中攻击者指定大小的一块区域，其中包含来自攻击者请求之外的数据。

漏洞：致命错误回溯释放后使用

在受影响版本中，PHP 将最近一次致命错误的回溯保留在 EG(lastfatalerror_backtrace) 中。致命的内存不足错误会销毁请求堆，但不会取消定义该执行器全局变量。worker 存活下来，但其全局变量仍指向上一请求的内存。

如果同一 worker 在下一请求早期发出诊断信息，它可能在执行器重新初始化该状态之前访问该指针。PHP 随后销毁或更新悬空的回溯，并跟随攻击者重新占用的内存。由此产生的跨请求释放后使用可被发展成受控的内存损坏。我们使用这一原语演示了针对 Drupal 的未认证远程代码执行。

漏洞：OPcache 类型混淆

OPcache 将编译后的 PHP 结构持久化在共享内存中，并把索引分配到每个 worker 的运行时指针映射中。worker 通过共享前沿（frontier）协调这些索引。在 zendaccelscriptpersist() 期间，PHP 推进进程本地的 CG(mapptr_last) 前沿。它仅在持久化完成后才发布对应的共享前沿。若这两个事件之间发生分配失败，进程本地的前沿推进会保留下来，而部分持久化的对象仍引用共享状态认为可用的槽位。

当另一个 worker 后来把这些槽位之一复用于不同的运行时对象时，陈旧的共享元数据会解析为错误类型的指针。这种不匹配造成跨 worker 类型混淆，并损坏共享的 OPcache 状态。我们使用这一原语构建了针对 WordPress 的未认证 RCE 利用链。

除了这四个漏洞之外，还有其他变种。虽然我们最初向 PHP 报告了这四个漏洞，但通过这项研究我们意识到，该问题在 PHP 代码库中根深蒂固，需要全面修复。其他变种也应归入同样的两个 CVE。

结论

由于互联网 70% 的网站受到影响，PHP2Shell 的影响再怎么强调都不为过。它标志着一个 AI 拐点。易受攻击的代码已存在十多年——AI 改变的是理解这些弱点并将其转化为可用漏洞的能力。借助前沿 AI 模型和正确的工具，一名研究人员在一周内完成了以前需要世界级团队数月才能完成的工作。

这改变了发现和攻击的成本结构。曾经看似不切实际、难以利用的漏洞成为可行目标。同样的这些能力也让防御者有机会发现并修复那些历经多年审查仍未发现的缺陷。

Wiz 在整个研究过程中使用了 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol，其中 Argon 在发现漏洞和帮助修复漏洞方面贡献尤为突出。

机遇在于让这项工作成为常态：系统性地发现现有软件中的缺陷，并在新缺陷进入生产环境之前捕获它们。我们与 PHP、OpenAI 和 Calif 的协调努力推进了这一目标，应用 AI 来加强我们所有人共享的软件基础。

负责任的披露时间表

• 2026 年 8 月 19 日： Wiz Research 使用 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol 发现了第一个 PHP 漏洞。
• 2026 年 8 月 20 日： 确认针对 Drupal 的未认证 RCE。
• 2026 年 8 月 21 日： 确认针对 WordPress 的未认证 RCE。
• 2026 年 8 月 24 日： Wiz Research 向 PHP 安全团队报告漏洞。
• 2026 年 9 月 21 日： PHP 确认报告，并开始开发协调修复方案。
• 2026 年 10 月 21 日： 已修补的 PHP 版本发布。
• 2026 年 10 月 21 日： 公开披露。

讨论整体被质疑和不安主导：多数人并不买账“AI 首次发现 PHP 漏洞”的叙事，而是把矛头指向品牌营销、两个月披露窗口中的疑似泄露，以及 Wiz、Calif、OpenAI 等多方重复发现与抢功的混乱。少数人则把焦点拉回漏洞本身，认为其未认证 RCE 波及 WordPress、Drupal 等，严重性可比 Log4Shell 与 EternalBlue，并忧心 PHP 承载约七成网站带来的现实风险。

认为所谓“AI 发现”更多是营销包装，而非真正突破

• 漏洞埋在至少二十年前的代码里，AI 能找到并不稀奇；研究方未披露算力成本，却营造出“人类史上首个 RCE”的叙事，还配上完整品牌用于变现，技术深挖部分也被指像 LLM 写的灌水内容，读完仍不懂机制。若 AI 能“发现”它，很可能它早已进入训练数据、甚至已在野利用。（较多人） > “买我们的产品，因为我们发现了一个漏洞”，而你们还把它泄露了出去。（@mg794613）

质疑披露时间线异常、疑似泄露且多方抢功

• 从报告到公开披露有两个月，且 PHP 安全团队隔了一个月才确认；有人发现相关报告其实五年前就出现过。Wiz、Calif、OpenAI 与更早的 LCFR_HAX 似乎都参与或重复发现了该问题，加上公关动作和漏洞提前泄露，让人难以厘清谁先发现、谁在抢功，很多人呼吁一份由熟悉 PHP 的人撰写的中立事后复盘。（较多人） > 我越查越糊涂，只希望由没刻意回避 PHP 的人写一份基于事实的事后复盘。（@Topfi）

认为漏洞本身极端严重，影响面被严重低估

• 漏洞能直接在 WordPress、Drupal、Joomla 等上实现未认证 RCE；有人根据技术细节判断它比 Log4Shell 更糟，堪称与 EternalBlue 并列史上最严重漏洞之一。PHP 支撑约七成网站，这让人感到不安，也出现“该把 Nextcloud 这类 PHP 应用换成不是垃圾堆的东西”的吐槽。（少数人） > 如果需要参照物，这比 Log4Shell 还严重，是公开史上最严重的两个漏洞之一，堪比 EternalBlue。（@schleck8）

认为这再次证明大型代码库不可能正确，必须极端精简代码

• 写作正确软件几乎不可能；既然 AI 都能在高曝光项目中不断挖出漏洞，那么数十万行代码的区块链项目迟早会被攻破。由此出现激进主张：把代码行数压到最低，攻击面必须清晰、可枚举、且在所有条件下可测试。（少数人） > 我以前是代码极简主义者，现在成了激进极简主义者，必须把代码行数降到最低。（@jongjong）

有价值的补充

• 技术归类上，五到六个问题被映射到 2 个 CVE：Wiz 一方（GPT-5.6 Sol 与 Gemini 4 Argon）覆盖远程进程内存泄露、OPcache 类型混淆、致命错误回溯 UAF，并在 WordPress、Drupal、Joomla 上给出 POC；Calif 一方（使用消费级可用的 LLM）覆盖 Zend HashTable OOM，目标为 PHP-FPM 与 mod_php；双方都发现了上传进度反序列化器上的 UAF。（@airtnp）
• 利用链的关键疑点是：两篇文章都描述“释放后的内存仍留有指向它的指针”如何导致 RCE，但被指出跳过了最重要的一步——如何把任意写变成执行。问题是：需要同时任意写内存并跳转到该地址，还是直接覆盖 PHP 字节码再让解释器执行？（@WJW）
• 缓解措施方面，有人问 Red Hat 系上的 SELinux 是否能限制损失、至少阻止 shell 启动；用 FORTIFY_SOURCE 等 Red Hat 推荐编译标志构建的 PHP 是否有帮助。其自建的 rhel7 系统会把用户提供的 LDAP 凭据中继到域控制器，在这类漏洞前可能完全敞开。（@chasil）
• 验证与脉络：有人求可用于验证补丁是否生效的可靠代码来源；PHP 基金会的事后说明被感谢“把这一切解释清楚了”。（@wildmXranat、@fwlr）
• 冷知识：Plone 是被巴西政府广泛使用、且被人认为是少数安全性未被攻破的全功能 CMS，用来回应“有没有适合大型组织的安全 CMS”的疑问。（@rbanffy）