PHP2Shell 从崩溃隐患变为远程攻击，约 47% 的 PHP 网站仍在运行未修补的旧版本

AI 大幅降低寻找漏洞的成本，过去被视为「顶多让程序崩溃」而搁置的旧漏洞，如今可被串联成真正的攻击。IEEE Spectrum 于 11 月 2 日评论以 PHP2Shell 为例说明：此问题在 2024 年仅被视为崩溃隐患；网络安全公司 Calif 审计 PHP，报告称可在未登录的情况下远程执行任意代码。

PHP2Shell 的根源：内存不足时留下半成品数据，事后被当成正常数据使用

根据 PHP 基金会的事后说明，PHP2Shell 的根源是内存不足（OOM）。通俗地说，当请求恰好在用完内存上限的那一刻进入，PHP 会留下半成品的内部数据，之后又将这些数据当成正常数据使用，导致内存遭到破坏。

此类错误通常会导致程序崩溃。哥伦比亚大学计算机科学系副教授 Suman Jana 指出，待修清单中总有大量崩溃报告，多数人并不将其视为严重问题。

2024 年仅是理论推想，2026 年审计 12 天即找到远程执行路径

据报道，PHP 这项问题在 2024 年外部审计期间，已有核心开发者看到迹象，但当时仅停留于理论推想，尚未找到攻击路径。到了 2026 年，Calif 从 7 月 30 日开始审计 PHP，12 天后报告称此旧问题能让攻击者无需登录即可远程执行任意代码。

Jana 表示，编写此类攻击程序并非高深科学，主要是大量琐碎且费力的推理工作，而 AI 在这方面表现很好。

AI 的角色：放大专家能力，但无法独力完成全部工作

据 Jana 说明，AI 无法独自完成所有工作，其作用是让顶尖 0.1% 的专家能做更多事，也让略低一层的人无需熟悉所有细节即可完成相关任务。

Calif 研究员 Ryan Austin 在说明页面中也指出，此次初步发现使用的是普通人可获得的模型，关键仍在于研究者熟悉这段程序过去曾出现哪些漏洞；他的结论是：「没有哪个模型靠简单提示就能挖出所有 bug。」

修补的不对称与版本分散：修补需确保攻击链全数堵截且不破坏既有功能

Jana 指出，找 bug 与修 bug 之间存在根本的不对称。修补时必须确认攻击的每个环节都被堵上，同时不能破坏既有功能。以 PHP 为例，2024 年看到迹象后，各种修法都有代价：有的会破坏兼容性，有的需改动大量第三方扩展模块，工作因此反复停摆，基金会自称是「结构性失败」。

版本分散也让修补更困难。据 W3Techs 统计，官方此次仅为 PHP 8.2 至 8.5 推出正式修补版，覆盖约 53% 的 PHP 网站；其余约 47% 的网站仍运行官方未推出正式修补版的旧版本。

修补版发布后的实测：未更新服务器约 19 小时遭攻破

据报道，PHP 基金会表示，发布时并未看到可用的攻击程序。但修补版发布后的几天，一名开发者刻意架设了未更新的 PHP 服务器并公开悬赏，约 19 小时后即遭攻破。

技术债是否还得完：Matthew Green 认为没有重大事件前，多数人不会主动修补

约翰霍普金斯大学信息安全研究所副教授 Matthew Green 对此持较悲观的看法：在没有发生重大事件前，多数人不会主动修补；他认为，PHP2Shell 的严重程度尚不足以引发广泛行动，真正促使各方投入资源的大事件可能在 2027 年初发生。以上为 Green 的个人研判，并非已发生的事实。

常见问题

PHP2Shell 是什么？为何原本只被视为崩溃问题？

根据 PHP 基金会说明，PHP2Shell 源于内存不足（OOM）情境下的内部数据处理错误：请求在内存用尽的瞬间进入，PHP 留下半成品内部数据并随后当作正常数据使用，造成内存破坏。此类错误通常只导致程序崩溃，因此长期被视为待修清单中的一般报告。

此漏洞的修补版目前覆盖多少 PHP 网站？

据 W3Techs 11 月 6 日统计，官方仅为 PHP 8.2 至 8.5 推出正式修补版，这几条版本线约涵盖 53% 的 PHP 网站；其余约 47% 的网站仍运行官方未推出正式修补版的旧版本。

AI 在这次漏洞事件中扮演什么角色？

据 Calif 审计与哥伦比亚大学副教授 Suman Jana 的说明，AI 在编写攻击程序的大量推理工作中表现良好，能让顶尖专家做更多事，也降低略低一层人员的门槛；但 AI 无法独自完成所有工作，研究者仍需熟悉程序过去的漏洞历史。