ARTICLE · 1231977
AI找出了潜伏20年的PHP后门,70%的网站都在用(附普通人也能照做的漏洞自查清单)
最近,美国开源安全公司 Wiz 的研究团队,借助 AI 智能体,在 PHP 核心引擎里挖出了两个 CVSS 最高 9.2 的严重漏洞(CVE-2026-109618、CVE-2026-109619)。同一批漏洞,OpenAI 牵头的「Patch the Planet」计划用 GPT-5.6 Sol 也独立发现了一处。
这两个洞有多老?最早可以追溯到 PHP 5.4,也就是 2004 年发布的那一代。二十多年。
有多广?PHP 支撑着全球约 70% 的网站、超过 3300 万个站点——WordPress、Drupal、Joomla、维基百科的 MediaWiki,全都跑在它上面。而且漏洞不在这些应用里,在 PHP 自己身上:哪怕你只写了一个「Hello World」,只要跑在受影响版本的 PHP 上,它就是目标。
美国国家安全局(NSA)发出的警告很直接:如果你的网站没法立刻打补丁,那就先把它下线。

01 这到底是个什么东西
先说结论式的技术描述,再说不该被吓到的地方。
所有披露的漏洞都是内存安全问题,根子在 PHP 处理"致命错误"(尤其是内存分配失败)的方式上:请求意外结束后,PHP 可能留下一段"已经死了但还没被清干净"的内部状态。后续请求如果被同一个 worker 复用,就可能读到脏数据——轻则泄露内存,重则被攻击者当成内存破坏的原语,一路做到远程代码执行。
Wiz 把它归成两类 CVE,覆盖四个可利用实例:
上传进度反序列化器释放后使用 → 远程进程内存泄露 → 在 WordPress、Drupal、Joomla 上实现未认证 RCE;
致命错误回溯释放后使用 → 在 Drupal 上未认证 RCE;
远程进程内存泄露 → 即使应用从没调用过
session_start()也能生效,攻击者可以把 worker 内存里的密码、令牌、API 密钥、证书读出来;OPcache 类型混淆 → 跨 worker 共享内存被污染,在 WordPress 上完成未认证 RCE。
关键判断标准写在前面:不需要你的网站代码有漏洞。WordPress、Drupal、Joomla 只是演示用的靶子,不是必要条件。
还有个更狠的能力:攻击者甚至不需要拿到 RCE,光靠内存泄露就能读到属于其他用户请求的数据。换句话说,一个访客的会话、后台管理员的令牌,都可能从 PHP 进程的内存里被拖出去。
值得记一笔的是,官方给出的定性是目前没有在野利用报告——漏洞是研究者在黑客之前发现的。原因很简单:在 AI 之前,这些漏洞难到没人愿意碰。
02 二十多年的漏洞,为什么一周就被挖出来了
这是整件事里最值得琢磨的部分。
Wiz 自己把过程写得很清楚:这些缺陷的底层代码存在了十几年,但要证明它们"真的能被利用",需要串起多个缺陷,还要考虑 PHP 在不同请求之间如何分配和复用内存。内存 bug 本身就以复杂著称,PHP 版本、配置、应用行为的差异都可能直接打断利用链的假设。
针对一个部署调通的利用,转到另一个部署上,往往要反复分析、测试、调试——每次都要重来一遍。
在 AI 之前,这种活儿很难做,更难规模化。
Wiz 的原话是:有了 AI,这不再是障碍。LLM 可以帮攻击链适配不同的 PHP 版本、配置和内存布局;配合测试调试工具,模型能分析失败原因并迭代调整,把每个目标所需的专家投入大幅压缩。
Wiz 研究团队的结论直接点破了经济学层面的变化:
「借助前沿 AI 模型和合适的工具,一名研究员在一周内完成了过去世界级团队需要数月才能完成的工作。」
他们给出的时间线也很说明问题:
8 月 19 日:Wiz 用 AI 智能体发现第一个 PHP 漏洞
8 月 20 日:确认针对 Drupal 的未认证 RCE
8 月 21 日:确认针对 WordPress 的未认证 RCE
8 月 24 日:向 PHP 安全团队报告
9 月 21 日:PHP 确认收到,开始协同修复
10 月 21 日:修复版本发布,同日公开披露
发现到披露,整整两个月。
Wiz 把这件事和 Heartbleed(2014)、Log4Shell(2021)并列,说它可能标志着 AI 时代的同类转折点。我同意这个类比的分量——但要补一句他们没展开说的:
Heartbleed 和 Log4Shell 揭开的都是"防护网有洞";而 PHP2Shell 揭示的是另一件事:当写利用代码的成本塌方,"没被发现"和"不可利用"之间的距离被抹平了。
过去的漏洞之所以躺了二十年,不是因为安全界不知道内存安全重要,而是因为没人算得过来那笔账。攻击者要付出的人力成本太高,不值得。现在这笔账的算法变了。
03 AI 第一次站到了漏洞披露方的位置上
OpenAI 在这篇官方博客里做的事,比"我们用 AI 找到了个漏洞"要重得多。它顺手提出了一套AI 时代的漏洞响应框架,这才是这件事真正值得中文互联网关注的部分。

先把关键动作列出来:
第一步,把漏洞发现和修复摆到台面上一起做。Calif 参与 OpenAI 的「Patch the Planet」计划,用 GPT-5.6 Sol 发现了其中一处严重缺陷;Wiz 也独立发现并报告了这两个漏洞;PHP 维护者主导了修复与发布——注意这个顺序,AI 不是主角,AI 是加速器。
第二步,留出"防守方的窗口期"。OpenAI 提出了一个叫 Defender's Window 的概念:前沿 AI 在攻击者之前发现漏洞,从而给维护者和安全厂商留出准备修复和防护措施的时间。这个词是本次事件的题眼。
第三步,把响应流程拆成五个阶段,值得抄下来:
在上游验证并修复漏洞——维护者、研究者和关键技术伙伴确认问题、评估影响、开发并测试修复,其中包含用前沿模型做对抗性测试,专门去找绕过补丁的方法和相关变体;
给受影响机构留出行动时间——维护者决定提前通知谁;发行商适配老版本,托管商测试缓解措施,安全厂商准备 WAF 规则和检测方案;
与政府伙伴协同保护关键系统——这次 PHP 事件里,OpenAI 说他们与白宫 Super Intelligence Force、美国网络总监办公室(ONCD)、CISA 以及国际伙伴协作;
让下游产品同步准备更新;
补丁就绪后发布指引并支持部署验证。
同时明确了几条"边界纪律":谁该提前知道、以什么形式知道、泄露了怎么办、发现有人拖延修复怎么办——这套规则的核心不是"保密",而是把保密义务和保护义务绑在一起。
第四步,给没钱的防守者兜底。OpenAI 承诺拿出 10 亿美元补贴版 Daybreak 访问权限,专门给资源有限、却要保护关键服务的机构;给所有开源维护者提供 Codex 订阅;成为 Rust Foundation 铂金赞助方。
第五步,给站长一个能立刻用的自查工具。OpenAI 同步发布了一个 Codex 技能(php2shell-checker),帮运维快速确认自己跑的 PHP 版本是否受影响、该升到哪个版本。这是个很务实的动作——漏洞 disclosed 之后,最稀缺的不是技术,是"我到底该不该动手改"。
顺便说一句,就在同一天,Anthropic 也发布了用 Claude 自动化攻击面分析与缩减的研究:在 25 个、超过 500 万行代码的开源项目里发现 493 个问题。两个团队、同一天、同一个方向——AI 做防守已经从个案变成工程化常态,而不再是新闻。
04 同一把刀,另一面朝着攻击者
OpenAI 自己在博客里就把这句话说透了:
「它凸显了 AI 如何以互联网规模的影响发现安全缺陷,但同样的能力也能帮助攻击者快速开发进攻工具和利用代码。」
Wiz 的表述更狠:
「随着这项工作所需的时间和专业知识减少,复杂性可能不再构成有意义的障碍,从而改变我们在实践中界定何为易受攻击的方式。」
翻译成人话:"这个洞太复杂所以没人利用"这个借口,从今天起失效了。
而且漏洞现在已经公开。TechCrunch 的标题起得很不客气——《PHP Armageddon》。当防守方还在给几千万个网站排队打补丁时,攻击者已经拿到完整的技术细节了。
这就是 AI 时代漏洞攻防最拧巴的地方:发现和利用,共用同一套能力。
而更要命的是,这次的事件还只是一个开始。OpenAI 自己的原话是:这类漏洞"只是我们已经发现并在修复的若干重要漏洞之一,我们预计类似发现在未来几个月会急剧增加"。
顺带说一个同周的镜像事件,作为参照:美国军方 ARCYBER 正在采购一项代号 ECHOTRIBBLE 的自主智能体工具,承包商答疑文件里明确写着它"主要用于攻击",机制接近蠕虫——静默跨设备跳转、中和目标、任务完成后自毁。目前还只到选标阶段,尚无可用工具,但方向已经很清楚了。
一边是 AI 在帮我们挖二十年的老洞,另一边是 AI 被写进"会自己扩散、自己删日志"的采购单里。同一套能力,两个方向同时踩油门。 这是 2026 年最真实的安全图景。
05 如果你手里有 PHP 网站:一份能照做的清单
这部分建议直接转给管服务器的人。
1. 先查版本,别先慌。目标版本是 PHP 8.5.12(已发布修复版)。特别注意:PHP 8.1 及更早版本已经停止官方支持,如果你还跑在 5.x / 7.x 上,这次可能是"顺手一起升级"的机会。可以用 OpenAI 发布的 Codex 技能 php2shell-checker 做快速自查。
2. 立刻更新。Cloudflare、Akamai、AWS、Microsoft、Imperva、Vercel、Fastly、Automattic 这些基础设施和托管方都已经在准备 WAF 规则和兜底缓解措施,但官方立场很明确:打补丁是唯一完整的修复,WAF 只是过渡期缓解。
3. 如果实在修不了,先下线。这是 NSA 的建议原文:无法立即打补丁的站点,应当下线,直到能打上补丁为止。听起来夸张,但漏洞是未认证 RCE——不需要账号,不需要权限,一个请求就能进来。这不是"存在风险",这是"等着被进"。
4. 别只修 CMS,要修 PHP 本身。WordPress 官方也发声明说得很清楚:这不是 WordPress 特有漏洞,跑 WordPress 的站点必须给服务器(也就是 PHP)打补丁,和你的 CMS 应用版本是两件事。很多人在这里会犯"我已经升了 WordPress 啊"的错。
5. 如果不能马上打补丁,去看日志找异常。Wiz 给的检测信号很具体,值得直接转给运维:
异常的多部分(multipart)请求之后,紧接着出现内存限制错误或反复的 HTTP 500;
异常大、或者格式错误的 PHPSESSID 响应 cookie;
PHP worker 频繁更替,且无法解释。
原因是漏洞发生在应用层之下,应用日志往往上下文很少。注意:这些只能用来调查和发现,不能替代打补丁。
06 这件事真正在改变什么
我不打算把文章写成"AI 好棒"或"世界完蛋",那样没意思。这件事真正值得记住的,是三条更结构性的东西。
第一,漏洞的存在时间和被修复的时间,正在被拉近到同一条线上。过去二十年的补丁滞后,本质是经济问题:修一个 70% 网站都在用的语言的核心内存 bug,收益巨大,但 PHP 核心团队是开源小团队,审报告、评影响、在多个支持版本上回补测试,人力极其有限。这次 OpenAI 直接出钱出人出模型,Wiz 出研究成果,一堆基础设施厂商配合做缓解——这不再是靠志愿者热情维持的开源安全,而是被重新定价后的开源安全。
第二,"披露"这件事本身需要被重新定义了。过去漏洞披露是安全圈内部的君子协定:给维护者 90 天,然后公开。今天这个问题不再成立——因为从发现到可武器化之间的时间,可能只有几天。OpenAI 在文末抛出的几个问题,每一个都是真问题:防守方到底需要多少准备时间?什么证据该触发提前披露?政府该不该在自己失去管理权限时动用漏洞来修补自己的系统?
第三,也是我最想留给读者的一条:AI 正在同时改变攻防两边的经济学,而两边的变化速度是对称的。防守方这边:一人一周干完世界级团队几个月的活。 攻击方那边:把利用链适配到不同版本、配置和内存布局,"不再是障碍"。
对称意味着,任何"AI 让网络安全变好了"的判断都必须打个问号。真正可靠的策略不是"用 AI 防 AI",而是:把补丁流程缩短、把暴露面缩小、把可观测性做扎实。因为你没法靠工具更聪明来抵消对手工具更聪明带来的收益——但你可以靠流程更快来抵消。
对个人也一样。你不需要会写利用代码,但你要知道两件事:你的网站跑在什么语言和版本上,以及它多久没更新了。 这两个问题的答案,今天在互联网上都可能有决定你是安全的还是被开着的。
尾巴
二十年前,PHP 的维护者写下那段处理内存错误的代码时,没有人做错什么。代码没有错,逻辑没有错,它只是在一个更早的年代里,恰好没有人有力气去证明它可以被利用。
二十年后,一个 AI 智能体用一周时间,把这件事做完了。
这大概是 AI 时代最好的一个隐喻:真正稀缺的从来不是漏洞,而是能把它变成现实的那双手。 当这双手变便宜、变快、变多,安全团队的第一反应不该是恐慌,而是——把补丁这件事,排到今天最前面。
你手上的网站,跑的什么语言、哪个版本?多久没更新了?
主笔:「黄浩在观察」的 OpenClaw
编辑 · 审核 · 发布:黄浩在观察
封面图 : GPT-Image-2.5
AI·时刻

Prompt:从这个标题【AI找出了潜伏20年的PHP后门,70%的网站都在用】中选取关键词,适当搜索,适度发挥创意,采用与内容主体适配的色系,生成合适的公众号封面图,比例21:9
AI系列文章:
结婚 9 周年之际,我用 AI 把 486 张照片、278 段视频,做成了一支婚礼 MV 和一本故事画册
企业AI落地真相:公司宣传的,和员工感受到的,根本不是一回事
百度文心大模型5.1预训练成本暴跌94%!国内AI格局会有新变化吗?
宇树G1机器人完成全球首例活体手术,还在《自然》期刊发表了论文!
手机跑27B大模型、数据不出本地:端侧模型正在攻克手机AI的“最后一公里”















































































