全球 70% 网站一夜告急，日本首相催打补丁，详解PHP暴雷事件始末

全球约七成网站昨夜遭遇紧急安全警报，一场由PHP引发的安全风暴席卷网络空间。

美国国家安全局（NSA）与英国国家网络安全中心（NCSC）等机构同步发布警告，指出PHP系统中出现两项高危漏洞，敦促相关组织立即采取防御措施。NSA进一步强调，这些漏洞极为严重，若网站无法迅速修复，应将其暂时关闭，直至补丁部署完成。攻击者可借此侵入服务器的文件系统或网络应用程序所使用的数据库。

日本首相高市早苗也在社交平台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在特定阶段发生严重错误，部分内部状态可能未被重置。当同一工作进程处理下一个请求时，程序可能访问已释放的内存，即“释放后使用”问题。这可能导致PHP工作进程崩溃，影响网站服务。在满足特定条件时，攻击者还可能借此远程执行恶意代码。目前，研究人员已确认该漏洞可造成内存错误和进程崩溃，并在Apache mod_php的真实环境中成功演示了远程代码执行。

这两个问题均源于PHP中几乎每个请求都会用到的部分：内存管理和错误处理。它们在PHP中的核心地位使得漏洞极为严重，修复也异常困难，因为任何改动都可能破坏兼容性、损害性能，或迫使庞大的第三方扩展生态做出调整。

如此严重的漏洞是如何被发现的？事实上，这两个漏洞并非近期新发现。根据PHP基金会披露的完整时间线，相关内存管理问题的早期迹象早在2024年就已由人类开发者发现。只是当时缺乏明确的利用路径，加之修复方案涉及复杂兼容性问题，导致问题长期未获彻底解决。

安全公司Calif表示，2004年其研究员Stefan Esser就曾发现PHP内存限制机制中的远程代码执行漏洞。由于危险程度高，他未公开完整利用程序，随后CORE和Immunity等安全公司也分别开发了未公开的利用工具。Stefan Esser昨日在X上晒出了他2004年发现该漏洞时的邮件。

到了2020年，一名研究人员向PHP官方报告了编号#78876的问题，指出某些超长变量可能导致内存耗尽，并使临时文件无法正常清理，但未引起足够重视。今年8月，多家安全研究团队借助前沿AI模型，陆续证明相关缺陷可被利用，并发现了更多攻击路径。

更具体的时间线始于2024年的一场外部安全审计。PHP基金会获得德国Sovereign Tech Agency资金支持，通过Open Source Technology Improvement Fund（OSTIF）组织审计，由安全公司Quarkslab负责。这也是PHP多年来首次开展此类外部审计。在修复Quarkslab报告的问题时，一名受PHP基金会资助的核心开发者注意到，PHP处理内存耗尽异常时可能存在内部状态管理缺陷。正常情况下，PHP接收请求后需完成初始化并在结束时清理资源。但若内存耗尽发生在关键阶段，程序可能提前退出，留下未初始化的数据结构。后续代码若继续使用这些数据，可能引发内存破坏。这正是后来编号为CVE-2026-109618的漏洞根因。

当时，PHP开发者已从理论上意识到问题可能被利用，却始终未找到具体攻击路径，更无法证明可远程执行代码。修复工作也远比想象困难。PHP安全团队研究了多种方案，但每种都有代价：可能破坏兼容性、带来拒绝服务风险，或需大量第三方扩展配合修改。在缺乏明确利用证据的情况下，安全团队难以判断应承担哪种代价。加之具备PHP引擎底层知识的核心开发者有限，修复工作反复启动又停滞。在10月21日的复盘中，此次拖延被称为“结构性失败”，承认问题出在安全决策流程和维护资源不足。

为应对AI时代安全报告增长带来的维护压力，今年5月，PHP基金会成立了生态系统安全团队，与PHP安全团队协同工作。团队成员包括Volker Dusch、Alexandre Daubois和Daniel Scherzer等技术专家。Volker Dusch是资深PHP开发者，拥有约20年从业经验，曾参与PHPUnit维护及PHP语言改进提案，也是PHP 8.5版本发布负责人之一。2026年5月，他出任PHP基金会首任常驻AI安全工程师，领导新团队。Alexandre Daubois是法国公司Les-Tilleuls.coop的CTO，熟悉Symfony、FrankenPHP等开源项目，2026年7月加入PHP基金会，协助处理安全报告分类、验证和修复。Daniel Scherzer是PHP核心贡献者，负责维护Reflection扩展，2026年9月以短期成员身份加入，重点处理增强安全性和稳定性的代码问题。

安全研究公司Calif受邀参加OpenAI发起的“Patch the Planet”计划，决定将PHP作为审计目标。7月30日，Calif启动研究，通过安全专家Stefan Esser联系PHP基金会的Volker Dusch，推动合作。Calif披露，团队原本认为PHP已接受大量审计，不易发现严重漏洞。但重新审查历史问题并结合Esser的研究后，团队仅用几天便发现一个严重的内存耗尽漏洞，并找到可用于攻击WordPress网站的远程代码执行路径。此后，研究人员又发现了适用于Apache mod_php和PHP-FPM环境的攻击路径。

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等人组成，Gemini 4 Argon在漏洞发现与修复辅助中发挥了重要作用。与Calif类似，Wiz并非简单找到一行错误代码，而是围绕PHP的异常处理、对象生命周期和跨请求内存状态，证明了这些底层缺陷可导致实际攻击。Wiz公布的分析显示，其研究涉及四种可利用缺陷实例，被归入CVE-2026-109618和CVE-2026-109619，包括会话上传进度反序列化引发的释放后使用、进程内存泄露等。Wiz还将攻击技术组合为PHP2Shell利用演示，在WordPress、Drupal和Joomla等环境中验证了未经身份验证的远程代码执行风险。不过，这些应用仅是验证目标，漏洞本身位于PHP引擎，并非各系统独有的缺陷。

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四个安全版本，修复了两项漏洞。回顾整个过程，AI的实际贡献并非自主找到bug并修复，而是帮助研究人员发现和验证复杂利用路径，使长期存在的底层缺陷从理论隐患变为必须立即处置的高危漏洞。Wiz在技术报告中指出，相关漏洞根因已存在十余年，真正困难的是构造完整利用路径。过去，这可能需顶尖团队投入数月；如今，借助前沿AI模型与适当工具，一名研究人员在一周内即可完成类似任务。

就在PHP官方发布补丁当天，外部研究人员也开始独立复现和分析漏洞。10月21日，安全研究人员Qi Deng在Substack发布技术文章《PHP2Shell：剖析PHP严重漏洞》，记录了自己对PHP源码的分析及验证过程。Qi Deng表示，他花费约24小时搭建实验环境，逐行审查源码，尝试从头构造利用路径。文章声称，研究过程中发现了五条可能实现远程代码执行的路径，包括不在此前泄露的PoC中的攻击思路。文章中最值得关注的是两类与官方漏洞直接相关的机制。第一类：内存耗尽导致PHP在未初始化完成时进入清理流程。正常情况下，HTTP请求到来时，PHP需初始化环境、解析输入、执行代码并清理资源。但Qi Deng分析发现，在Apache mod_php部署方式下，请求体解析可能在代码执行前发生。若某请求在此阶段触发内存耗尽，PHP会通过longjmp()等非局部跳转机制退出。问题在于，这种退出可能跳过部分初始化操作。随后，Apache mod_php仍执行清理流程，而部分内部状态未被正确初始化，清理代码便可能访问无效内存。Qi Deng在实验中展示了内存耗尽后程序仍进入异常清理路径的现象。PHP官方安全公告确认，此问题在Apache mod_php特定条件下，可在默认配置中实现无需身份验证的远程代码执行，且攻击发生在应用程序代码运行之前。这意味着，即使网站无业务逻辑漏洞，也不能排除运行时层面的风险。第二类：前一个请求的异常状态可能影响后一个请求。另一项漏洞涉及PHP对全局状态的管理。PHP-FPM等部署方式使用持续运行的工作进程处理多个请求。理想情况下，每次请求结束后，内存和状态应正确清理。但当某次请求发生致命错误或内存耗尽时，正常重置流程可能被跳过。若全局指针仍指向前一个请求已释放的内存，后续请求访问时可能造成释放后使用问题。Qi Deng通过GDB调试器观察了请求初始化及会话反序列化的顺序，并展示了异常请求留下的状态被后续处理逻辑读取的情况。这类问题难以发现的原因是，单独测试任何请求都可能无法触发完整漏洞，只有当两个请求按特定顺序进入同一工作进程，且前一次留下异常状态时，问题才暴露。从这些分析可见，本次安全问题的共同特征是：异常退出后，PHP不同模块间的内存与执行状态可能不一致。在复杂软件中，这类问题不如传统输入验证漏洞直观，可能隐藏在多个函数、请求及资源生命周期之间，成为AI辅助安全研究的应用场景。

此次PHP漏洞事件也引发了一个问题：AI究竟在多大程度上改变了传统漏洞挖掘方式？它是取得了突破性进展，还是仅让自动化安全研究更高效？360漏洞研究院专家对InfoQ表示，此次事件可看作“专家经验×通用大模型”协作模式的一次验证。它说明大模型对代码语义的理解能力，正帮助研究人员突破传统方法的局限。专家认为，此次漏洞的难点不在于发现孤立的内存错误，而在于理解不同请求间复杂的状态变化。研究人员需弄清程序何时完成初始化、什么情况下被异常中断，以及中断后的状态如何影响后续执行。只有将这些环节联系起来，才能判断一处普通异常是否真的能被利用。传统安全工具在处理此类问题时存在局限：模糊测试主要生成大量输入寻找异常，对需多条件连续触发的漏洞可能覆盖不足；静态代码分析更擅长识别已知危险模式，却可能遗漏跨模块、跨请求的复杂逻辑问题；人工审计虽能结合经验判断，但受代码规模、时间和精力限制。相比之下，大模型能从代码含义和执行逻辑入手，关联分析不同文件模块间的关系，帮助识别潜在异常路径。不过，专家特别强调，AI具备深入分析能力，并不意味着它天然知道从哪里开始寻找漏洞。“这次研究里，发现者恰恰是先靠对2004年Esser系列内存限制远程代码执行漏洞的历史经验，明确了研究方向，再借助大模型深入分析，几天内就找到了一个此前经过人工安全审计、却仍然存在的深层漏洞。”在专家看来，AI最重要的价值是帮助研究人员将分散在不同模块中的信息联系起来，缩短漏洞验证所需时间。“单独看某个异常，它可能只是程序中断，或资源耗尽；要证明它可利用，必须把不同模块的执行顺序、状态残留、后续请求串起来分析。”他认为，AI可借助代码理解和关联推理，将这些分散线索组合成可验证的攻击路径。“这个案例最直观的一点就是：AI加快的，正是从‘发现异常’到‘证明可利用’这一段的速度。”但AI提出的分析结果不一定正确。专家指出，大模型可能生成看似合理、实际无法成立的漏洞假设。对于复杂漏洞，攻击路径由多个环节组成，任何一步推理错误都可能导致结论不成立。因此，模型提出假设后，仍需研究人员通过代码审查、动态调试和实际测试验证。“模型给出的是需要验证的漏洞假设，不是天然成立的安全结论。”在他看来，更可行的技术路线不是让大模型完全取代传统工具，而是将其与模糊测试、静态分析、动态验证和人工审计结合，形成从发现疑点到确认漏洞的完整流程。

随着AI参与越来越复杂的漏洞研究，另一个问题也随之出现：如果防御方可借助AI快速找到漏洞，攻击方是否也可利用同样技术更快发现和利用缺陷？360专家认为，这种变化已开始发生。从技术能力看，大模型能帮助使用者理解复杂漏洞原理、分析触发条件，并编写验证测试代码。过去需长期积累专业知识的部分工作，如今可借助AI降低操作难度。同时，AI也在改变人员投入方式。过去需多人合作的代码分析、调用关系梳理和风险排查，现在一名研究人员借助AI即可承担相当一部分工作。但这种能力提升不会自动让网络更安全。专家认为，从短期看，攻击方可能更容易从AI普及中获益。原因在于，攻击者通常只需找到一个突破防御的薄弱环节，而防御方需持续保护大量系统。“短期确实是攻击方更容易吃到红利：因为攻击者只需要找到一个可行的突破口，而防御方要持续保护大量系统。”不过，他也认为，这并不意味着防御方必然处于劣势。企业和安全团队同样可利用AI加快代码审计、漏洞验证、风险排查及补丁测试。“关键不是谁拥有AI，是谁能更快把AI能力用到实战里。”实际上，AI辅助漏洞挖掘已开始进入企业日常工作。据专家观察，越来越多企业尝试将AI智能体引入代码审计和漏洞研究流程。过去，一次深入人工审计可能需要数天甚至数周，研究人员需逐步梳理代码结构、函数调用关系和潜在风险。现在，部分初步分析可交由AI完成，安全专家则将更多时间投入复杂问题的判断与验证。但企业是否真正获得更高的漏洞发现率、更低的误报率及更好的投入产出比，仍需结合实际测试结果评估。尤其是对于复杂的底层内存漏洞，发现可疑代码并不等同于确认安全风险，验证和修复仍需专业工程能力。此次PHP漏洞事件正好说明了这一点。AI并未让安全专家失去价值，反而使研究人员积累的历史经验、漏洞知识和代码理解能力能以更高效率转化为实际发现。对于未来的安全研究，专家给出的判断是：“安全专家的经验判断和大模型的分析能力不是互相替代的关系，而是在形成一种新的协作方式。专家的知识和经验，正在通过大模型转变成更强的漏洞发现能力。”如果您希望进一步了解相关安全工具，可访问mk官方网站获取更多信息。

参考链接： 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”（ID：infoqchina），作者：冬梅，36氪经授权发布。