php2shell 不是新漏洞的名字有多吓人,而是它的影响面:PHP 核心里的两个远程代码执行漏洞(CVE-2026-109618 与 CVE-2026-109619)藏在 5.4 时代的老代码路径里整整 14 年,任何人都能在不需要登录的前提下,在你的服务器上跑任意程序。这篇把原理、AI 在挖掘中扮演的角色、71 天的修复窗口、全球暴露面,以及普通站长今天该做的四件事一次讲清。

一、10 月 21 日晚上,三个国家同时按下暂停键

时间线是从日本当地时间 10 月 21 日晚上十点开始的。日本首相高市早苗发布了一条消息,第一句就是「紧急」:PHP 存在两个严重漏洞,当晚 23:00 会发布补丁,如果你在用 PHP 网站,请做好立刻修补的准备,来不及就先关站。这条消息在社交平台上的浏览量超过了 4800 万次。

10 月 21 日晚的紧急通知:两个严重漏洞,当晚 23:00 出补丁,来不及就先关站

两小时之内,美国 NSA 与 FBI 给出同样口径的表态:能更新就更新,来不及就先下线。

NSA 与 FBI 的建议:能更新就更新,来不及就先下线

荷兰的做法更直接——政府网站、几家主要机构的门户网站,甚至几家医院的网站直接下线;芬兰政府网站采取了同样处理。

让这么多国家同时紧张起来的,是一种 1994 年诞生的编程语言。它在程序员圈子里一直有个梗:「世界上最好的语言」。但这一次,被挖出来的不是某个 WordPress 插件,而是语言本身。

二、PHP 到底有多关键:七成网站的后端

PHP 最早只是拉玛斯·勒多夫写的一套统计简历访问量的小工具,名字来自 Personal Home Page Tools。后来它成了专门建站的语言,WordPress 跑在它上面,Facebook 当年也建立在庞大的 PHP 系统之上,还专门为此做过一套更快的引擎。

W3Techs 统计:能识别后端语言的网站里,约七成在用 PHP

W3Techs 的口径是:在能识别出后端语言的网站里,PHP 占比约 69.3%。新闻里常见的「全球 70% 网站都用 PHP」其实有夸张成分,但即便按这个保守口径,它也支撑着互联网相当大的一块。

这决定了这次事件的性质:问题不在你的业务代码写得好不好,而在底下的运行时。

三、php2shell 漏洞长什么样:两个洞都出在「清理」这一步

不深入代码细节也能讲清楚大概。PHP 处理每个请求时,会为请求准备数据,处理完再把这些数据清理干净,好让下一个请求不受影响。两个洞都出现在这个清理阶段。

漏洞 触发条件 后果
CVE-2026-109618(OOM 内存破坏) 请求内存超限被掐断,清理时把「没初始化完」的数据当成有效数据 数组键写入路径被污染,可控函数指针表,直接落到远程代码执行
CVE-2026-109619(全局状态残留) 请求撞上致命错误后全局状态没被重置,下一条请求读到上一条请求的残留状态 跨请求 use-after-free,worker 崩溃;官方公告同时确认内存泄露影响

具体到攻击链:构造一个不声明 Content-Length 的 multipart 请求,里面再套一个不指定文件名的文件上传,PHP 仍会为文件元数据分配数组,内存迅速耗尽触发 OOM。OOM 之后 PHP 用 zend_bailout() 直接 longjmp() 跳出,而此时别的 C 代码还在处理那块内存——于是这块内存在之后会被当成「合法对象」再次使用,也就是典型的 use-after-free。顺带一提,同样的路径能把堆内存编码进 PHPSESSID cookie 回吐给攻击者,泄露的堆地址还能用来绕 ASLR。

两个洞都评了 9.2 分(满分 10),PHP 官方提前一天发布预告公告

两个漏洞的评分都是 CVSS v4.0 9.2。这里要纠正一个流传很广的说法:漏洞编号外泄时流传的「10.0」是错的,PHP 安全团队给出的正式评分是 9.2(详见 PHP 官方安全公告)。安全公司 watchTowr 的说法更直白——即使你的网站只有一行 Hello World,你一样可能被攻击,因为缺陷在 PHP 自己身上,跟你的代码写得多好无关。

受影响的不只是某一种部署方式:PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed 都在范围内,其中 mod_php 最危险,因为它能在网站自身代码开始运行之前就被未认证请求触发。

四、14 年的旧账:为什么这么难被触发

最早的受影响代码路径可以追溯到 PHP 5.4.0,也就是 2012 年。14 年里没人报出来,不是因为它不明显,而是因为它太难被稳定触发。

2024 年其实已经有人看到过裂缝:PHP 基金会通过主权技术基金(Sovereign Tech Agency)与 OSTIF 牵线,让 Quarkslab 做了一次多年来的首次外部安全审计。核心开发人员在修复审计发现的问题时,发现了 CVE-2026-109618 背后的 OOM 问题,但当时只能怀疑可能被利用,拿不出确凿的入侵路径。而修复方案每一条都有副作用:有的会破坏向后兼容,有的会引入新的拒绝服务风险,有的还要连带改大量第三方扩展、几乎无法协调;没有证据证明它真危险,加上掌握引擎深层知识的核心开发人员本就不多、还各自一身任务,决策过程反复拉扯,事情就一直拖着了。PHP 基金会在复盘里直接写明:这是结构性故障,既有决策流程的问题,也有资源不足的问题。

2024 年就有人看到过裂缝,但拿不出确凿的入侵路径

五、AI 把挖掘周期从「十几年」压到「几天」

到了 2026 年,节奏完全变了。

  • 7 月 30 日:安全公司 Calif 通过 OpenAI 的 Patch the Planet 项目进场,对 PHP 做审计。
  • 8 月 11 日:Calif 的研究员 Ryan A 报告了一条无条件远程代码执行,根因与 2024 年发现的 OOM 问题相同;OpenAI 独立报告了同一根因,8 月 24 日 Wiz 补充了更多攻击向量,9 月 18 日 OpenAI 又给出新的向量。
  • 8 月起:从 8 月 11 日起,修这个洞成了 PHP 基金会整个安全团队的第一优先级;Trail of Bits 随后也介入了 PHP 的审计。
  • 10 月 20 日下午:漏洞编号在 Hacker News 和社交媒体上传开。
  • 10 月 21 日 14:00 UTC:补丁紧急发布。

Calif 验证了针对 WordPress、Drupal、Joomla、Magento 等主流 PHP 应用的未认证远程代码执行。PHP 基金会公开致谢的研究方包括 Calif、OpenAI、Wiz、Trail of Bits、OSTIF、Quarkslab,这些团队都公开表示在研究中使用了大模型。独立研究者 Calif 的完整技术分析见 calif.io/php2shell。

所以「AI 几天就找到了人找十几年没找到的漏洞」这个说法,一半对一半不对:人确实早在 2024 年就看到了裂缝,只是证明不了它有多危险;AI 带来的真正增量不是「发现潜在问题」,而是把问题直接变成可复现、可利用的漏洞利用链。以前这一步需要专家手工构造,现在几天内就能拿出演示视频。

这也是我认为最该记住的一点:AI 不只是让找漏洞变快了,它让「证明这个洞到底有多危险」的成本塌了。验证成本一旦塌了,漏洞的产出速度就会跟着暴涨。

六、71 天:修复为什么这么慢

从 8 月 11 日报告,到 10 月 21 日补丁发布,中间隔了整整 71 天。OpenAI 给出的解释很直接:修复这个漏洞非常棘手,需要对 PHP 核心做重大改造。PHP 基金会在这次的发布说明里也承认,这是结构性故障,而不是某一个人的疏忽。

从报告到补丁,中间隔了 71 天

更现实的问题是人手。官方公告里点名的修复开发者只有 4 位,而他们手上的活远不止这一件:

官方记录里的修复开发者只有 4 人,7 月以来还公开处理了 15 个漏洞、100+ 份无效报告

数字 含义
4 人 官方记录里的修复开发者
15 个 仅 7 月以来公开处理的漏洞数
100+ 审查的报告,其中大量无效、重复或无法复现

顺带说一句,AI 在修复环节也出了力:PHP 基金会和 Alpha-Omega 合作用 Anthropic 的 Claude Mythos 扫过 PHP,又引入 OpenAI 的 Daybreak Red 去验证报告与利用链,报告的归并、去重也靠模型。但基金会的原话是:每一个判断、每一处补丁,最后还是由人来做。决定「哪些副作用可以接受、谁来签字担责」的,依然只有那几个人。这件事暂时没法用跑更多模型来解决。

七、提前两天泄露:协调披露是怎么崩掉的

标准流程本来是这样:先把补丁私下给 Linux 维护团队,再商定一个全球统一的时间,让所有人在同一时刻打上补丁。这次定的日子是 10 月 22 日。

结果提前两天就漏了

10 月 20 日下午 15:00 UTC 前后,两个漏洞的编号提前传开,而且附带了一个错误的发布时间和一个错误的 10.0 评分(真实是 9.2),技术细节倒是没泄露。PHP 当晚 19:30 UTC 就把预告公告发了出去,并把原定 10 月 22 日 14:00 UTC 的发布提前到 10 月 21 日 14:00 UTC。随后报告方之一又误发了一段演示视频,删掉之后副本仍在社交媒体上流传,直接加速了各种 PoC 的扩散。

更扎心的一幕发生在第二天早上:10 月 21 日 07:41 UTC,比协调发布早六个多小时,Chainguard 单方面打破了 embargo,提前发布了带修复的构建镜像——其他 PHP 用户还在等发布,攻击者已经能对着二进制补丁研究了。

官方补丁发布时距离编号泄露还不到一天。那么,当时已经有人动手了吗?

官方:没看到;Cloudflare:看到了攻击流量;侦察服务器:看到攻击尝试

  • PHP 基金会:发布时未发现可用的漏洞利用代码。
  • 美国网络安全机构:没发现攻击,但发现了攻击流量。
  • 安全公司:在蜜罐服务器上观察到针对它的攻击尝试。
  • Amazon Threat Intelligence:在 10 月 17 日的蜜罐网络里就观测到了一次利用尝试,比公开披露早了四天,并建议排查时从 10 月 17 日开始回溯,而不是从披露日算。

「有人尝试」不等于「有人得手」。但它说明确实已经有人盯上了。

八、暴露面有多大:「先关站」为什么不是开玩笑

几个数字放在一起看会明白问题有多严重:

  • Shodan 口径:公网上跑着 PHP 的主机超过 190 万台。
  • 研究者粗估:存在被利用风险的公网主机超过 130 万台。
  • 安全平台全网估算:在能看出版本的 PHP 服务器中,使用不受支持版本的数量约为受支持版本的 2.8 倍。

最后一条是最要命的。PHP 8.1 及更早的版本官方早已停止更新,基金会只提供了几个版本的源码 backport,需要你自己编译,不是即插即用;更老的版本连这个都没有。

找漏洞 → 修 71 天 → 补丁又提前泄露 → 装到一台台机器上,最后一步没人知道要多久

这也正是从日本首相到 NSA、FBI 都给出同一个建议的原因:跟不上,就暂时置身事外。这不是怂,这是当前最不依赖运气的策略。官方态度也很清楚——目前没有完全解决方案,只有升级是安全的;网上流传的「改改上传相关设置就能挡住」只是挡住一条路,后续几项分析已经把那个说法纠正了。

临时缓解措施(仅部分有效,不是完整修复):

措施 作用范围 注意
memory_limit=-1 挡住 CVE-2026-109618 的 OOM 触发路径 应用不可覆盖该设置
session.upload_progress.enabled=0 收紧 CVE-2026-109619 的一条利用链 改完必须重启所有 PHP worker
fatal_error_backtraces=0(PHP 8.5) 减少全局状态里可被投毒的 backtrace 仅 8.5 有此开关
容器 / cgroup 内存上限 作为可用性边界 官方明说不是完整缓解
WAF 规则 Cloudflare 已对全部客户(含免费版)下发 官方明确称为「临时止损」,只覆盖经 Cloudflare 的流量

CERT-EU 的建议更进一步:暂时无法更新的组织,应把面向公网的应用从公共网络上隔离出去。

九、漏洞赏金这条产业链的副作用

找到漏洞能拿钱,这是行业运转了几十年的基本逻辑。但当找漏洞的边际成本塌到接近零,另一面就出来了。

3 月底,HackerOne 开源赏金计划暂停接收新报告

  • Google VRP:10 月 2 日起暂停接收开源产品的漏洞提交,理由是自动化提交的报告激增,且绝大多数无效。
  • curl:维护者 2026 年 1 月直接关掉了 HackerOne 赏金计划,起因是 AI 生成的无效报告洪水。
  • HackerOne 互联网漏洞赏金计划:3 月 27 日起暂停接收新提交,原因同样是 AI 让漏洞出现得更快、更多,而开源侧跟不上修复速度。

Google VRP 公告:自动提交的报告大量增加,绝大多数不是有效漏洞

这跟 PHP 身上那 100 多份无效报告是同一件事,而且这只是愿意举报的那部分人。

另一面是攻击者。10 月 17 日,开源 AI 编程工具 OpenCode 披露被入侵,约 1.4% 的 Console 用户受影响,存放在工作区里的 OpenAI、Anthropic、Gemini 等 API 密钥泄露,被用于大规模模型蒸馏攻击,有用户一晚之间被刷掉上千美元。开发者表示攻击持续了 48 小时,并且使用了 AI agent——他们调侃说,现在基本需要自己的 agent 全天候盯着那些「发现漏洞却不报告」的人。

十、普通站长今天该做的四件事

如果你有网站,或者用 AI 搭了什么东西,先把这四件事弄清楚:

先搞清楚四件事:PHP 版本、谁负责升级、能不能先下线、有没有人已经进来过

  1. 底下的 PHP 版本是多少? 是 PHP 版本,不是 WordPress 版本。很多产品表面上看不出用了 PHP,实际在后台跑着。
  2. 谁负责升级? 平台是否已经替你升了,还是你自己打包自己管?升完记得重启 PHP worker,并确认当前跑的就是新版本。
  3. 实在升不了,能不能先下线? 隔离比暴露安全。
  4. 有没有人已经进来过? 在网站目录里翻额外的文件、找未知的管理员账号——这些活现在完全可以让 AI 干。

OpenAI 在官方公告发布两个多小时后就补了一条:把 Codex 指向 openai/php2shell-checker 这个仓库,就能照着它做一遍检查——有服务器权限的直接查服务器上的 PHP 配置,只有网址的走站点查询。

OpenAI 官宣两个多小时后补了一条:让 Codex 照着 openai/php2shell-checker 查一遍

但有两个坑必须知道:这个工具只检查版本号,网站把版本号藏起来它就只会告诉你「未知」;仓库文档里写得很清楚——「未知」不等于已经修复;而且它不覆盖「是否已经被植入后门」这一项。所以更稳的做法是:以最权威的模型从上到下扫一遍你的站点;如果条件允许,在服务器上常驻一个 agent,每天检查有没有新的安全公告或可疑改动。

最后两个纪律:初期只给 agent「只读」权限,要改必须你点头;别把大量 API 密钥放在攻击者够得着的地方。

如果你连网站都不管,还有一件事可以做:任何存放在各类 AI 工具里的 API 密钥,一旦收到违规通知,立刻吊销、重新生成,顺便查一下账单。OpenCode 那次泄露的就是平台上的密钥。

十一、修复版本与自查清单

「十万火急,请大家今晚就处理」:几天找到、71 天修好、装到每台机器上要多久还没人知道

分支 修复版本 说明
PHP 8.5.x 8.5.12 已发布
PHP 8.4.x 8.4.27 已发布
PHP 8.3.x 8.3.36 已发布
PHP 8.2.x 8.2.35 已发布
PHP 7.4.x ~ 8.1.x 无官方版本 官方提供最小源码 backport,需自行编译
PHP 5.4.x ~ 7.3.x 无 已 EOL,官方不再修复,只能升级
PHP 5.4.0 ~ 各分支修复版 — 全部受影响,升级是唯一完整修复

如果你用发行版或 LTS 厂商的包,去查对应厂商的公告(它们通常提前拿到了补丁);如果是自编译,直接按上面的版本号升级,并在升级后逐台确认 worker 真的换了版本。

总结

这次 php2shell 事件留下的结论,我觉得有三条:

  1. 升级是唯一完整的修复。 其余都是临时缓解。8.1 及更早的版本没有官方二进制补丁,那 2.8 倍的存量设备,才是这次事件真正的风险面。
  2. AI 改变了漏洞经济学。 它压缩的不只是「找」的时间,而是「证明有多危险」的成本——这一头压下去,漏洞的产出速度、通报洪水和赏金生态的失衡就一起涌了上来。
  3. 别问「是不是 AI 的锅」。 问「修好了吗?装完了吗?」才是有意义的问题。

接下来几个月,类似的新闻只会越来越多,难度也会越来越高——因为工具链的进步是单向的。如果你的站点还在 PHP 8.1 甚至 7.x 上,今天就把它排进日程;如果确实排不进去,那就先下线。等待观望不丢人,前提是你清楚自己在等什么。

你所在的组织有没有被这次事件打个措手不及?升级排期卡在哪里?欢迎在评论区聊聊,或者把你的排查步骤贴出来,给后面遇到同样问题的人当参考。

参考资料

延伸阅读:
Codex 半年更新全盘点:4 个省 Token 硬技巧 + 8 个新奇玩法 ·
Claude 订阅长期稳定使用指南:干净 IP、自建中转与养号节奏 ·
MiniMax M3.1 Flash 实测:70 亿 Token 主力模型与 Agent 自动剪辑实践