本文来自微信公众号： InfoQ ，作者：冬梅，原文标题：《全球 70% 网站一夜告急，日本首相催打补丁！详解PHP暴雷事件始末》
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
