PHP爆雷引发全球紧急「拔网线」，别指望 AI 拯救互联网

互联网的惊魂 48 小时，正在上演。

图｜来源：连线

昨天晚上，欧洲多国的政府网站在同一时间陆续下线。

芬兰交通与通信局把部分在线服务关了；荷兰的电子身份系统 DigiD、荷兰政府的个人服务平台 MijnOverheid、政务门户全部暂停服务，甚至连荷兰国家网络安全中心自己的网站都一度关闭……

在日本，多个知名互联网社区平台，日本最大的插画/漫画/小说投稿社区 pixiv、日本老牌弹幕视频网站 Niconico、pixiv 旗下的创作者电商平台 BOOTH 等平台都宣布了紧急维护。

向左滑动查看更多内容

甚至还有寿司郎，也在官方平台宣布因系统维护升级，今天小程序暂停运行。

让这么多机构如临大敌的，是两个刚刚公开编号的漏洞： CVE-2026-109618 和 CVE-2026-109619 。

安全社区给它们起了个直白的绰号 PHP2Shell 。意思是攻击者往你的网站发一个请求，就能在你的服务器上拿到一个 shell（命令行入口），也就是为所欲为的控制权。

10 月 21 日，PHP 官方发布紧急更新 8.5.12、8.4.27、8.3.36 和 8.2.35，同时确认：两个漏洞的严重程度均为 CVSS 9.2 分（满分 10）， 不需要账号密码就能远程利用。

且在 Apache，即世界上用得最久的开源 Web 服务器软件，PHP 最常见的部署方式下，攻击在网站自己的代码开始运行之前就已经触发。

一个「满分漏洞」的谣言，结果是真的

这场风暴的开场颇具戏剧性。

按照原计划，漏洞细节应该在 10 月 22 日协调披露。但 10 月 20 日下午，Hacker News 上出现了一条帖子，宣称 PHP 存在两个评分 10.0 的远程代码执行漏洞。

图｜来源：Reuters

尽管帖子很快被删，但截图已经传开。有安全公司 watchTowr 几小时内就出面确认，这份泄露属实，漏洞是真的，而且他们已经复现了其中一个。

PHP 安全团队当晚紧急发布预警，把发布时间提前了 24 小时，并罕见地加了一句：「如果漏洞细节被公开，或者出现在野利用（ in-the-wild exploitation）的证据，我们保留进一步提前发布的权利。」

混乱还在继续。当晚，参与发现漏洞的安全公司 Calif 误发了一段演示视频，展示他们的攻击代码在多个真实目标上跑通，视频副本随即在社交平台疯传。

上下滑动查看更多内容

第二天早上，提前拿到补丁的发行商 Chainguard 又单方面打破保密协议，抢先发布了含修复的镜像。补丁本身就是一份「漏洞地图」，攻击者只要对比新旧两个版本的二进制文件，看改了哪段代码，就能反推出漏洞的位置和原理。

PHP 基金会事后的复盘里，对这个漏洞被公开的方式感到非常愤怒。

发现这种级别的漏洞后，行规是研究者、厂商、发行商约好一个统一时间，之前谁都不许公开细节。目的是让补丁和漏洞信息同时到达公众：用户一知道漏洞就能立刻有补丁可装，防守方的时间窗口最大。

出事方是互联网的地基

要理解这次事件为什么可怕，需要先理解 PHP 是什么。

它是互联网的「后厨」。我们在前台登录、搜索、下单、评论，PHP 在服务器里处理请求、读写数据库、把结果送回浏览器。 WordPress 、Drupal、Joomla、Magento、维基百科背后的 MediaWiki——全部跑在 PHP 上。

根据 W3Techs 的数据，在可以识别服务端技术的网站中， 69.3% 使用 PHP ；第二名 JavaScript 只有 8.1%。

我们在白帽汇做的国产网络空间测绘搜索引擎 FOFA 里也检索了含有 WordPress 的全网记录，能看到为什么率先响应的是欧美、日本等地区，因为匹配到 WordPress 指纹规则的资产条目数，这些地区最多。

过去大多数「PHP 网站被黑」的新闻，问题出在某个插件或某个应用身上。这次的漏洞位于 PHP 解释器内核 ，和上层应用无关。用发现者之一 Wiz 的话说：「 哪怕你的网站上只跑着一个 Hello World，也照样受影响。 」

两个漏洞的技术原理都不算新鲜，厉害的是它们被证明「真的能用」。

CVE-2026-109618 ：PHP 处理「内存耗尽」的方式是粗暴地急刹车（longjmp）。

如果刹车恰好踩在某个微妙时刻，内部数据只初始化了一半，后续的清理流程却会把这堆半成品当作正常数据处理，而攻击者可以借此让服务器执行自己的代码。

官方已验证：默认配置下，通过构造特制的 multipart 请求把内存「刚刚好」耗尽，就能在应用代码运行前完成攻击。

CVE-2026-109619 ：一个请求处理完、内存被释放后，某些全局状态没有清干净。

同一个工作进程处理下一个请求时，可能又去使用这些已经失效的内存，这种经典的「释放后使用」，可以被精心堆叠成代码执行，还能泄露内存里其他用户的密码、令牌和 API 密钥。

值得注意的是，已证实的利用路径之一经过的 session.upload_progress（会话上传进度）功能默认开启，应用甚至不需要调用 session_start()。

修复版本目前只覆盖 PHP 8.2 到 8.5 四个分支，而 W3Techs 的同日数据显示，全部 PHP 网站里仍有 27.0% 跑在 PHP 7.x、7.7% 跑在 PHP 5.x ，这些早已停止维护的版本拿不到官方补丁。

计算机取证专家 Hal Pomeranz 提到「有太多嵌入式安装永远不会被打补丁，太多被遗忘的、无人维护的应用。这一次，长尾会很长。」

AI 找到了它？一周，和数月

漏洞一公开，OpenAI 发文，将这次事件列入自己的 AI 安全成果：Calif 研究人员使用 GPT-5.6 Sol 找到了关键缺陷，多个团队合作完成验证与应对。

熟悉 AI 公司宣传套路的我们，大概会下意识多问一句：真是模型挖出了漏洞，还是又给人类的研究成果贴上了 AI 标签？

披露当天，Calif 在 X 上公开「正名」，称 Ryan Austin 才是第一个发现并做出可用攻击代码的人，证据是他 8 月 5 日就发出了一条含发现哈希的推文。

在漏洞第一发现者自己写的官方技术复盘，也是本次事件最重要的一手材料之一。

Ryan 在文章里面强调，初次发现没有依赖特殊的工具框架，也没有使用公众拿不到的模型。 他对目标历史的了解，决定了往哪里追查 ；简单提示词还做不到让模型找出所有漏洞。

他笔下的发现链一路追溯到 2004 年 Stefan Esser 找到的第一个 PHP 内存限制漏洞、2020 年一份被忽视的 bug 报告，以及 2024 年那场没能证明可利用性的审计。

图｜来源：https://calif.io/php2shell

言下之意就是 AI 压缩的只是验证的时间，而方向感，仍然来自人。

PHP 基金会的复盘也确认，OpenAI 团队在 8 月 11 日独立报告了相同根本原因，之后又补充了攻击路径。他们在文章里详细记录了漏洞是怎么被发现和修复的，以及披露了失控的完整记录。

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

2024 年，PHP 接受了多年来首次外部安全审计，一名核心开发者在修复审计发现的问题时，就注意到了内存耗尽处理的隐患。

但当时 没人能证明它真的可以被利用 ，几种修复方案又各有代价，可能破坏兼容、可能引入新的拒绝服务风险，团队迟迟无法拍板，问题被搁置了。 PHP 基金会事后称之为一次「结构性失败」 。

2026 年夏天，三个团队带着 AI 工具，几乎同时发现了这个问题：

8 月 1 日，安全公司 Calif 的研究员 Ryan Austin 在 OpenAI 的 GPT-5.6 Sol 帮助下发现首个漏洞，8 月 11 日报告 PHP 团队；OpenAI 同日独立报告了同一根因。

8 月 19 日，谷歌旗下的 Wiz 用自己的平台 Wiz Atlas，配合 Gemini 4 Argon 和 GPT-5.6 Sol 独立发现漏洞；随后两天内，先后在 Drupal 和 WordPress 的官方镜像上验证了无需登录的远程代码执行。

「这类内存管理风险很早就有人注意过，但长期被认为太难以至于无法利用。」Calif 的 CEO Thai Duong 对《华尔街日报》说。

图｜OpenAI 报告链接 https://openai.com/zh-Hans-CN/index/coordinated-disclosure-of-critical-vulnerabilities/

AI 把理论缺陷变成可用的攻击代码，需要串联多个环节、针对每个目标的内存布局反复调试。过去这是世界级团队数月的活，现在一个研究员加前沿模型，一周就能完成。

Wiz 联合创始人 Ami Luttwak 称这是「迄今由 AI 协助发现的最严重漏洞」，并将其与那些同样深埋于互联网地基、潜伏多年才爆发的传奇漏洞 Heartbleed、Log4Shell 并列。

一场没有终点的修补

漏洞确认后的两个月里，PHP 维护者主导修复，Calif、Wiz、OpenAI 参与验证，Google Cloud、Cloudflare、AWS、微软、Automattic、Fastly、Akamai、Vercel 等厂商提前准备缓解方案，Linux 发行版和长期支持厂商提前拿到补丁。

Cloudflare 则宣布其 WAF 防护规则对包括免费版在内的全部客户默认生效，为此他们上线了一项新能力「全事务检测」，把请求和源站响应关联起来判断攻击是否得手。

即便如此，Cloudflare 当天就观测到了针对客户的攻击流量，以及攻击者不断变形载荷试图绕过规则的尝试。

OpenAI 在报告中也提到已经开源了一个 Skill，可以安装到 Codex 里，专门用来检测网站是否存在 php2shell 漏洞。

安装方式，直接发送下面这句话到 Codex。

「$skill-installer install both skills from https://github.com/openai/php2shell-checker」，

检查的方法则是使用对应的 Skill，并附上链接。如果你拥有该网站的服务器访问权限时使用 phpcheck-server，当你只有 URL 时使用 phpcheck-url。

对普通用户来说，这件事最直接的感受就是，某些网站可能因为紧急维护，而导致我们短暂无法登录。

但对任何运营着网站或服务的人来说，要升级到修复版本，要重启所有 PHP 进程，还要给拿不到补丁的老版本安排迁移或隔离。

国内一些大量跑在宝塔面板、ThinkPHP 和 Discuz 上的长尾站点，它们中的老版本这次拿不到官方补丁，只能靠迁移或隔离来兜底。

而对于整个行业，PHP2Shell 留下的是一道更长的影子。OpenAI 在复盘里承认： 帮助研究者识别严重缺陷的能力，同样可以帮助攻击者更快打造攻击工具 。

补丁公开的那一刻，攻防双方拿的是同一份代码修改记录，所谓「防守方窗口期」，正在变成需要被精确计算的资源。

十多年前，这些缺陷被写进 PHP 的代码里时，没有人能用上它们。

如今 AI 把它们翻了出来，这一次，它们先在防守方手里。

图｜摇摇欲坠的互联网

我们有理由肯定 AI 在这次事件中的贡献， 研究者借助 AI，能够继续追查线索、分析失败原因，把过去难以完成的尝试推进下去。

但证明漏洞可以被利用，往往就意味着做出了一套能够运行的攻击代码。模型在这个过程中展现出的分析和调试能力，也可能被用来改进攻击工具。

随着这类工作的门槛下降，维护者需要应对的威胁也会增加。

这次，研究者提前提交报告，为修复争取了时间。以后这样的准备时间还能剩下多少，却很难预料。

AI 可以越来越快地找出问题并验证问题，但整个互联网能否跟上修补的速度，仍然是另一回事。

我们正在招募伙伴

简历投递邮箱hr@ifanr.com

✉️ 邮件标题「姓名+岗位名称」（请随简历附上项目/作品或相关链接）