PHP2Shell事件详解：两个高危漏洞迫使PHP紧急发布四个安全版本

原创冬梅 2026-10-22 16:57 北京

安全专家警告：短期内，攻击者可能更占便宜

作者｜冬梅

1 PHP 突然暴雷，全球 70% 网站或受影响

昨晚，一场围绕 PHP 的安全危机席卷互联网。

美国国家安全局（NSA）、英国国家网络安全中心（NCSC）、等安全机构相继发出警告，称 PHP 中发现了两个关键漏洞，要求相关组织尽快采取防护措施。

美国国家安全局进一步表示，这些漏洞非常严重，如果网站无法立即修复，则应将其下线，直到修复完成。这些漏洞允许攻击者渗透服务器的文件系统或网络应用程序可能使用的数据库。

日本首相高市早苗也在 X 上向日本全国发出紧急通知，请求普通民众 21 日晚就采取行动。

她写道：“关于许多网站所使用的 PHP，PHP 安全团队已就两个严重漏洞发出警告。请检查您对外公开的网站是否使用 PHP，并准备尽快应用将于 10 月 21 日晚上 11 点（日本时间）发布的修复补丁。如果难以及时应用修复补丁，暂时停用网站等措施可以被视为降低风险的有效方式。”

作为服务器端编程语言，PHP 被广泛应用于 Web 应用程序，据统计，互联网上大约 70% 的网站都使用 PHP 编写，超过 3300 万个网站。它也被 WordPress 等流行的内容管理系统所采用。

随后，PHP 官方紧急发布四个安全版本，修复两个严重程度评分均达到 9.2 分的高危漏洞。

引发这场风波的，是两个存在于 PHP 底层的内存安全漏洞，编号分别为 CVE-2026-109618 和 CVE-2026-109619，被安全社区统称 PHP2Shell。

那么，这两个漏洞究竟是什么，又会带来哪些风险？

PHP 基金会在 10 月 21 日发布的复盘文章中，对两个漏洞的原理及影响进行了说明。

第一个漏洞是 CVE-2026-109618，主要与 PHP 处理内存不足的方式有关。

简单来说，PHP 在运行过程中需要使用服务器内存。如果某个请求恰好在特定阶段触及 PHP 设置的内存使用上限，程序就可能提前中断，导致部分内部数据尚未完成初始化。

问题在于，PHP 后续仍可能把这些不完整的数据当作正常数据使用，从而引发内存错误。攻击者如果能够利用这种错误，就可能在服务器上执行恶意代码。

这一漏洞的危险之处在于，在使用 Apache 和 mod_php 的服务器上，攻击者不需要登录网站，就可能通过特制请求触发漏洞，甚至不需要等到网站的业务代码开始运行。研究人员已经证明，在默认配置下，这一漏洞可以被用于远程代码执行。

此外，研究人员也在使用 PHP-FPM 的环境中，通过特定应用程序代码的执行路径验证了远程代码执行的可能性。

第二个漏洞是 CVE-2026-109619，主要与 PHP 没有正确清理上一次请求留下的内存状态有关。

正常情况下，服务器处理完一个请求后，应当清理不再需要的内存数据，为后续请求做好准备。

但研究人员发现，如果 PHP 在特定阶段发生严重错误，部分内部状态可能没有被正确重置。当同一个工作进程继续处理下一个请求时，程序就可能访问上一次请求已经释放的内存。

这种情况在技术上被称为“释放后使用”（Use-after-free）。它可能导致 PHP 工作进程崩溃，使网站服务受到影响。在满足特定利用条件时，攻击者还可能借此远程执行恶意代码。

目前，研究人员已经确认了这一漏洞能够造成内存错误和进程崩溃，并在使用 Apache mod_php 的真实应用环境中，成功演示了远程代码执行。

这两个问题都出在 PHP 中几乎每个请求都会用到的部分：内存管理和错误处理。它们在 PHP 中的核心地位使得这两个漏洞非常严重，而且修复起来也极其困难，因为一旦修复，就可能破坏兼容性、损害性能，或者迫使庞大的第三方扩展生态系统做出改变。

这么严重的漏洞是如何被发现的？

2 漏洞被发现的完整时间线

事实上，这两个漏洞并不是最近新发现的。根据 PHP 基金会披露的完整时间线，相关内存管理问题的早期迹象，早在 2024 年就已经由人类开发者发现。只是当时缺少明确的漏洞利用路径，修复方案又涉及复杂的兼容性问题，导致问题长期未能得到彻底解决。

安全公司称，内存漏洞 2004 年已经发现

根据安全公司 Calif 的表述，2004 年 Calif 安全研究员 Stefan Esser 就曾发现 PHP 内存限制机制中的远程代码执行漏洞。当时漏洞的危险程度很高，他没有公开完整的利用程序，随后 CORE 和 Immunity 等安全公司也分别开发了未公开的漏洞利用工具。

Stefan Esser 昨天在 x 上晒出了他 2004 年发现该漏洞时的邮件。

到了 2020 年，一名研究人员又向 PHP 官方报告了编号为 #78876 的问题，指出某些超长变量可能导致内存耗尽，并使临时文件无法正常清理，但这份报告当时没有引起足够重视。

到了今年 8 月，多家安全研究团队借助前沿 AI 模型，陆续证明了相关缺陷能够被攻击者利用，并发现了更多攻击路径。

PHP 基金会称 2024 年再次发现内存漏洞

更具体的时间线，要从 2024 年的一场外部安全审计说起。

2024 年，PHP 基金会获得德国 Sovereign Tech Agency 的资金支持，通过 Open Source Technology Improvement Fund（OSTIF）组织外部安全审计，由安全公司 Quarkslab 负责实施。这也是 PHP 多年来首次开展此类外部安全审计。

在修复 Quarkslab 报告的一项问题时，一名受 PHP 基金会资助的核心开发者注意到，PHP 在处理内存耗尽（Out of Memory，OOM）异常时，可能存在内部状态管理缺陷。

正常情况下，PHP 接收请求后需要完成一系列初始化操作，并在请求结束时清理相关资源。但如果内存耗尽恰好发生在某个关键阶段，程序可能提前退出，留下没有完整初始化的数据结构。后续代码如果继续使用这些数据，就可能引发内存破坏。

这正是后来被编号为 CVE-2026-109618 的漏洞根因。

当时，PHP 开发者已经从理论上意识到这一问题存在被利用的可能，却始终没有找到具体攻击路径，更无法证明攻击者能够利用它远程执行代码。

而修复工作也远比想象中困难。

PHP 安全团队研究了几种不同方案，但每一种都有代价：有的可能破坏现有应用的兼容性，有的可能带来新的拒绝服务风险，还有的需要大量第三方 PHP 扩展配合修改。

在缺乏明确利用证据的情况下，安全团队难以判断应当承担哪一种代价。再加上具备 PHP 引擎底层知识的核心开发者人数有限，修复工作反复启动又陷入停滞。在 10 月 21 日发布的复盘文章中，将这次拖延称为一次“结构性失败”，承认问题既出在安全决策流程，也出在维护资源不足。

但问题摆在那也不能永远不解决吧。

为了应对 AI 时代安全报告数量增长带来的维护压力，今年 5 月，PHP 基金会成立了生态系统安全团队，该团队与 PHP 安全团队协同工作，负责安全问题的分类、协调和加固。团队成员包括 Volker Dusch、Alexandre Daubois 和 Daniel Scherzer 等技术大佬。

Volker Dusch 是资深 PHP 开发者，拥有约 20 年 PHP 生态从业经历，曾参与 PHPUnit 维护及 PHP 语言改进提案，也是 PHP 8.5 的版本发布负责人之一。2026 年 5 月，他出任 PHP 基金会首任常驻 AI 安全工程师，并负责领导新成立的生态系统安全团队，推动 AI 辅助漏洞检测、安全报告处理及开源项目安全治理。

Alexandre Daubois 是法国技术公司 Les-Tilleuls.coop 的 CTO，熟悉 Symfony、FrankenPHP、PHP 核心及 Scrutineer 等开源项目，具有丰富的软件安全问题处理经验。2026 年 7 月加入 PHP 基金会，主要协助安全漏洞报告的分类、验证和修复，缓解 AI 工具普及后安全报告数量激增带来的压力。

Daniel Scherzer 是 PHP 核心贡献者，负责维护 PHP 的 Reflection（反射）扩展，同时担任 PHP 8.5 的版本发布负责人及 PHP 8.6 的资深版本发布负责人。2026 年 9 月，他以短期成员身份加入 PHP 基金会生态系统安全团队，重点处理尚未构成正式安全漏洞、但有助于增强 PHP 安全性和稳定性的代码问题。

安全研究公司 Calif 受邀参加 OpenAI 发起的“Patch the Planet”计划，决定将广泛应用于互联网的 PHP 作为审计目标。

7 月 30 日，Calif 正式启动研究，并通过安全专家 Stefan Esser 联系到 PHP 基金会的 Volker Dusch，推动双方合作。

Calif 披露，团队原本并不认为还能轻易发现严重漏洞，因为 PHP 已经接受过大量安全审计。但在重新审查此前发现的问题、结合 Stefan Esser 的历史研究寻找线索后，团队仅用了几天时间，就发现了一个严重的内存耗尽漏洞，并找到了一条可用于攻击 WordPress 网站的远程代码执行路径。此后，研究人员继续寻找其他利用方式，又发现了适用于 Apache mod_php 和 PHP-FPM 环境的攻击路径。

OpenAI、谷歌只是提供了工具，并非 AI 自主发现了漏洞

8 月 11 日，关键突破出现。 Calif 研究人员 Ryan A 向 PHP 安全团队报告了一条能够实现远程代码执行的攻击路径，其根因恰好就是 PHP 核心开发者在 2024 年发现的内存耗尽问题。

同一天，OpenAI 也独立报告了相同的漏洞根因。

根据 OpenAI 官方说明，Calif 在研究过程中使用了 GPT-5.6 Sol，借助这一模型发现了关键安全缺陷。

按照这种说法，事实基本清楚了：GPT-5.6 Sol 只是在发现漏洞中使用的一个工具，并不是第一个注意到相关问题的主体，更不意味着两个漏洞都由 ChatGPT 在无人参与的情况下独立发现。

与此同时，谷歌旗下安全公司 Wiz 也在独立开展漏洞研究。

Wiz 在官方技术复盘中披露，其团队于 8 月 19 日使用 Wiz Atlas 安全智能体、Gemini 4 Argon 和 GPT-5.6 Sol，发现了第一项 PHP 安全漏洞。

8 月 20 日，Wiz 确认能够在 Drupal 环境中实现未经身份验证的远程代码执行；8 月 21 日，又在 WordPress 环境中验证了相同等级的攻击影响。

8 月 24 日，Wiz 正式向 PHP 安全团队报告相关漏洞。

Wiz 的研究团队由 Sagi Tzadik、Shir Tamari、Nir Ohfeld 和 Tomer Schwartz 等人组成。按照团队披露的信息，Gemini 4 Argon 在漏洞发现与修复辅助过程中发挥了尤其重要的作用。

与 Calif 的发现类似，Wiz 并不是简单找到了一行容易识别的错误代码，而是围绕 PHP 的异常处理、对象生命周期和跨请求内存状态，进一步证明了这些底层缺陷可以导致实际攻击。

Wiz 公布的技术分析显示，其研究涉及四种可利用的缺陷实例，被归入 CVE-2026-109618 和 CVE-2026-109619 两项漏洞。其中包括会话上传进度反序列化引发的释放后使用、进程内存泄露、致命错误回溯处理中的释放后使用，以及 OPcache 类型混淆等问题。

Wiz 还将相关攻击技术组合为名为 PHP2Shell 的漏洞利用演示，在 WordPress、Drupal 和 Joomla 等实际应用环境中验证了未经身份验证的远程代码执行风险。

不过，这些应用只是研究人员选择的验证目标，漏洞本身位于 PHP 引擎，并非 WordPress、Drupal 或 Joomla 各自独有的安全缺陷。

随后，9 月 18 日，OpenAI 再次报告了新的攻击路径，进一步补充了安全团队对相关底层缺陷的认识。

由此可以看出，2026 年夏天的突破并不是某一家公司独自完成的。Calif 首先报告了与 2024 年已知问题同源的严重远程代码执行路径，OpenAI 同日独立报告相同根因并在之后补充新的攻击路径，Wiz 则独立发现和验证了多个相关可利用问题。

这些研究成果让 PHP 安全团队最终确认，原本缺乏明确利用证据的内存安全缺陷，事实上能够导致严重的服务器入侵风险。

PHP 基金会表示，自 8 月 11 日开始，修复相关内存管理问题成为整个安全团队的最高优先事项。多名工程师投入全职开发，并持续与 OpenAI、Calif、Wiz 等研究团队协调，部分工作甚至延续至周末和夜间。

最终，经过约两个月的协调修复，PHP 官方于 10 月 21 日发布 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 四个安全版本，修复了 CVE-2026-109618 和 CVE-2026-109619 两项严重漏洞。

回看整个过程，AI 的实际贡献并不像很多媒体宣传得那样，自主找到 bug 并进行了修复，而是在于帮助安全研究人员发现和验证复杂的利用路径，使长期存在的底层缺陷从理论上的安全隐患，变成了必须立即处置的高危漏洞。

Wiz 在技术报告中给出了一个颇具代表性的判断：相关漏洞的根因已经存在十余年，真正困难的是构造完整、可靠的利用路径。过去，这项工作可能需要一支顶尖安全团队投入数月；如今，借助前沿 AI 模型与适当的研究工具，一名研究人员在一周内就可能完成类似任务。

3 开发者独立复现 PHP 漏洞流程

就在 PHP 官方发布补丁当天，外部研究人员也开始独立复现和分析这些漏洞。

10 月 21 日，安全研究人员 Qi Deng 在 Substack 发布技术文章《PHP2Shell：剖析 PHP 严重漏洞》，详细记录了自己对 PHP 源码的分析及漏洞验证过程。

Qi Deng 表示，他花费约 24 小时搭建实验环境，逐行审查 PHP 源码，并尝试从头构造漏洞利用路径。

文章声称，研究过程中发现了五条可能实现远程代码执行的路径，其中包括不在此前泄露的 PoC 中的攻击思路。

这篇文章中最值得关注的，是两类与本次官方漏洞直接相关的机制。

第一类：内存耗尽导致 PHP 在尚未初始化完成时进入清理流程。

正常情况下，当一个 HTTP 请求到来，PHP 需要初始化执行环境、解析输入数据、执行应用程序代码，并在请求结束时清理资源。

然而，Qi Deng 分析发现，在 Apache mod_php 部署方式下，请求体解析可能在应用程序代码执行之前发生。如果某个请求在这一阶段触发内存耗尽，PHP 会通过 longjmp() 一类非局部跳转机制退出当前执行过程。

问题在于，这种异常退出可能跳过部分正常初始化操作。

随后，Apache mod_php 仍然执行请求关闭和资源清理流程，而此时部分内部状态并未被正确初始化，清理代码便可能访问无效内存。

Qi Deng 在实验中展示了内存耗尽发生后，程序仍继续进入异常清理路径的现象。

PHP 官方安全公告进一步确认，这一问题在 Apache mod_php 特定条件下，可以在默认配置中实现无需身份验证的远程代码执行，而且攻击过程能够发生在应用程序代码真正运行之前。这意味着，即使网站自身没有明显的业务逻辑漏洞，也不能排除运行时层面的安全风险。

第二类：前一个请求的异常状态，可能影响后一个请求。

另一项漏洞涉及 PHP 对全局状态的管理。PHP-FPM 等部署方式通常使用持续运行的工作进程处理多个请求。理想情况下，每次请求结束后，相关内存和状态都应当正确清理或重置。

但是，当某次请求发生致命错误、内存耗尽或异常中止时，正常的状态重置流程可能被跳过。

如果某个全局指针仍然指向前一个请求已经释放的内存，后续请求再次访问它时，就可能造成释放后使用（Use-after-free）问题。

Qi Deng 通过 GDB 调试器观察了 PHP 请求初始化及会话反序列化的先后顺序，并展示了某次异常请求留下的状态被后续处理逻辑读取的情况。

这类问题难以发现的原因是，单独测试任何一个请求，都可能无法触发完整漏洞。只有当两个请求按照特定顺序进入同一个工作进程，并且前一次请求留下了异常状态，问题才可能暴露。

从这些技术分析可以看出，本次安全问题的共同特征是：异常退出后，PHP 不同模块之间的内存与执行状态可能不再保持一致。在复杂软件中，这类问题往往不像传统的输入验证漏洞那样直观。它们可能隐藏在多个函数、多次请求及不同资源生命周期之间，也正因此，成为 AI 辅助安全研究值得关注的应用场景。

4 AI 正在缩短从“发现漏洞”到“证明漏洞可利用”的时间

此次 PHP 漏洞事件也引发了一个问题：AI 究竟在多大程度上改变了传统的漏洞挖掘方式？它是取得了突破性进展，还是只让过去的自动化安全研究变得更高效？

360 漏洞研究院专家对 InfoQ 表示，此次事件可以看作“专家经验 × 通用大模型”协作模式的一次验证。它说明大模型对代码语义的理解能力，正在帮助安全研究人员突破传统漏洞挖掘方法的部分局限。

专家认为，此次 PHP 漏洞的难点，不在于发现某一处孤立的内存错误，而在于理解不同请求之间复杂的状态变化。研究人员需要弄清楚程序何时完成初始化、什么情况下会被异常中断，以及中断后留下的状态如何影响后续执行过程。只有将这些环节联系起来，才能判断一处看似普通的程序异常，是否真的能够被攻击者利用。

传统安全分析工具在处理这类问题时存在一定局限。模糊测试（Fuzzing）主要通过生成大量测试输入寻找异常，对于需要多个条件连续触发的漏洞，未必能够有效覆盖；静态代码分析更擅长识别已知的危险模式，却可能遗漏跨模块、跨请求的复杂逻辑问题。人工代码审计虽然能够结合经验进行判断，但又受到代码规模、审计时间和研究人员精力的限制。

相比之下，大模型能够从代码含义和执行逻辑入手，关联分析不同文件和模块之间的关系，帮助研究人员识别潜在的异常执行路径。

不过，专家特别强调，AI 具备深入分析代码的能力，并不意味着它天然知道应该从哪里开始寻找漏洞。

“这次研究里，发现者恰恰是先靠对 2004 年 Esser 系列内存限制远程代码执行漏洞的历史经验，明确了研究方向，再借助大模型深入分析，几天内就找到了一个此前经过人工安全审计、却仍然存在的深层漏洞。”

在专家看来，AI 在这一过程中最重要的价值，是帮助研究人员将分散在不同模块中的信息联系起来，缩短漏洞验证所需的时间。

“单独看某个异常，它可能只是程序中断，或者资源耗尽；要证明它可利用，必须把不同模块的执行顺序、状态残留、后续请求串起来分析。”

他认为，AI 可以借助代码理解和关联推理，将这些分散的线索组合起来，形成可进一步验证的攻击路径。

“这个案例最直观的一点就是：AI 加快的，正是从‘发现异常’到‘证明可利用’这一段的速度。”

但 AI 提出的分析结果，并不一定就是正确的。专家指出，大模型可能生成看起来合理、实际上无法成立的漏洞假设。而对于复杂漏洞来说，攻击路径往往由多个环节组成，任何一步推理出现错误，都可能导致最终结论不成立。

因此，模型提出漏洞假设之后，仍然需要安全研究人员通过代码审查、动态调试和实际测试进行验证。

“模型给出的是需要验证的漏洞假设，不是天然成立的安全结论。”

在他看来，更可行的技术路线不是让大模型完全取代传统安全工具，而是将其与模糊测试、静态分析、动态验证和人工审计结合起来，形成从发现疑点到确认漏洞的完整流程。

5 AI 降低漏洞挖掘门槛，攻防双方谁更受益？

随着 AI 参与越来越复杂的漏洞研究，另一个问题也随之出现：如果防御方可以借助 AI 快速找到漏洞，攻击者是否也可以利用同样的技术，更快发现和利用软件中的缺陷？

360 专家认为，这种变化已经开始发生。

从技术能力来看，大模型能够帮助使用者理解复杂漏洞的原理、分析触发条件，以及编写用于验证漏洞的测试代码。过去需要长期积累专业知识才能完成的部分工作，如今可以借助 AI 降低操作难度。

与此同时，AI 也在改变漏洞研究的人员投入方式。过去可能需要多人合作完成的代码分析、调用关系梳理和风险排查，现在一名研究人员借助 AI，就有可能承担其中相当一部分工作。

但这种能力提升，并不会自动让网络变得更加安全。

360 专家认为，从短期来看，攻击方可能更容易从 AI 的普及中获得收益。原因在于，攻击者通常只需要找到一个能够突破防御的薄弱环节，而防御方却需要持续保护大量系统，确保不同组件、版本和运行环境的安全。

“短期确实是攻击方更容易吃到红利：因为攻击者只需要找到一个可行的突破口，而防御方要持续保护大量系统。”

不过，他也认为，这种变化并不意味着防御方必然处于劣势。企业和安全团队同样可以利用 AI 加快代码审计、漏洞验证、风险排查以及补丁测试。

“关键不是谁拥有 AI，是谁能更快把 AI 能力用到实战里。”

实际上，AI 辅助漏洞挖掘已经开始进入企业日常安全工作。据专家观察，越来越多企业开始尝试将 AI 智能体引入代码审计和漏洞研究流程。过去，一次较为深入的人工代码审计可能需要数天甚至数周，研究人员需要逐步梳理代码结构、函数调用关系和潜在风险。现在，部分初步分析工作可以交由 AI 完成，安全专家则将更多时间投入复杂问题的判断与验证。

但企业是否真正从中获得了更高的漏洞发现率、更低的误报率以及更好的投入产出比，仍需要结合实际测试结果进行评估。尤其是对于复杂的底层内存漏洞，发现可疑代码并不等同于最终确认安全风险，验证和修复仍然需要专业工程能力。

此次 PHP 漏洞事件正好说明了这一点。

AI 并没有让安全专家失去价值，反而让研究人员积累的历史经验、漏洞知识和代码理解能力，能够以更高效率转化为实际发现。

对于未来的安全研究，专家给出的判断是：“安全专家的经验判断和大模型的分析能力不是互相替代的关系，而是在形成一种新的协作方式。专家的知识和经验，正在通过大模型转变成更强的漏洞发现能力。”

参考链接：

https://www.youtube.com/watch?v=cE4h79AWbT4

https://www.wiz.io/blog/php2shell-php-rce

https://openai.com/zh-Hans-CN/index/coordinated-disclosure-of-critical-vulnerabilities/

https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/

https://assets.theregister.com/2026/10/21/202622/

https://www.theregister.com/security/2026/10/21/php-devs-publish-critical-bug-fix-as-site-owners-warned-pull-em-offline-if-youre-unpatched/5304519

声明：本文为 InfoQ 原创，不代表平台观点，也不构成投资建议，未经许可禁止转载。