全球七成网站的地基裂了：AI 在攻击者之前发现了它，但真正的难题才刚刚开始
AI飞行客 全球七成网站的地基裂了：AI 在攻击者之前发现了它，但真正的难题才刚刚开始
昨晚半夜，全球的运维和 PHP 程序员大概都没睡好。
两个 CVSS 9.2 的超级漏洞被公开，统称 PHP2Shell，编号 CVE-2026-109618 和 CVE-2026-109619。最严重的情况下，攻击者无需登录就能在服务器上执行任意代码。从 PHP 5.4 开始几乎所有版本都中招，包括现在还有大量公司舍不得换的 7.x 和 8.0/8.1。
官方说得很直白：没有完整的缓解措施，唯一安全的做法是立即升级。
但问题是，8.1 及更早版本官方早就不支持了。想打补丁都没得打。
路透社报道，荷兰、芬兰的一些政府网站已经抢先下线。日本的同行也在连夜加班——霓虹的网站什么水平，懂的都懂。
全球七成网站跑在 PHP 上。这不是某个开源项目的 bug，这是互联网地基的一道裂纹。
然后最戏剧性的部分来了：这两个漏洞是 GPT-5.6 Sol 发现的。
先看漏洞本身有多脏
很多人看到”内存溢出”四个字就滑过去了，我建议你停下来看看这两条，因为它们是很典型的”现代 AI 才能翻出来”的深层缺陷。
CVE-2026-109618：通过 OOM（内存溢出）导致内部数据结构不完整，请求清理时把无效数据当成有效数据处理，最终造成内存破坏，通向 RCE。
翻译一下：系统内存撑不住的时候，清理流程会自我欺骗，把垃圾当成正常对象来操作。这不是某个函数的边界检查写错了，这是异常路径和正常路径的状态一致性问题——这种 bug 在代码评审里几乎不可能靠人眼看出来，因为它只在特定资源压力下才浮现。
CVE-2026-109619：请求相关的全局状态在内存释放后仍然残留，同一个 worker 处理的下一个请求会用到已经释放的内存——use-after-free，同样通向 RCE。
这条更致命。`use-after-free` 在 web server 的场景下意味着什么？意味着上一个请求留下的残渣可以被下一个请求读取或利用。在共享 worker 的部署模式下，这是天然的跨用户攻击面。
影响范围：PHP-FPM、Apache + mod_php、php-cgi、FrankenPHP、LiteSpeed 全部在列。其中 mod_php 风险最高。研究人员已经在部分 WordPress、Drupal、Joomla 部署上复现了未登录的远程代码执行。
WordPress 又是全球 43% 网站的底座。这个链条，你品一品。
谁发现的？一条不寻常的路径
OpenAI 的说法是：安全公司 Calif 使用 GPT-5.6 Sol 发现了 PHP 的关键漏洞；Wiz Research 独立发现并报告了同样的问题。
注意”独立发现”这四个字。两个不同的团队、两套不同的工具链，在相近的时间点撞到了同一批漏洞。 这反过来证明了漏洞的客观存在性，也让整个披露流程的可信度上了一个台阶。
具体怎么发现的？背景是 OpenAI 在 2026 年 6 月推出的一个开源安全倡议，叫 Patch the Planet（修复星球）。
这个计划的动机写得很直白，也是我认为整件事里最值得注意的一环：
> 模型能大量发现漏洞，但开源维护者人手严重不足，容易被海量报告淹没。所以 AI 不仅要 find bug，还要 debug。
这句话点破了一个所有人都在回避的问题。过去两年我们听了太多”AI 一天扫出 2000 个 CVE”的故事，听起来很爽，实际后果是：
– 维护者被淹 – 真正严重的漏洞被噪音掩盖 – 报告质量参差不齐，大量误报 – 开源维护者本来就是无偿劳动，被这么一冲，直接 burnout
AI 提升”发现”的效率，如果不同时提升”修复”的效率，产生的不是安全，而是混乱。
Patch the Planet 的思路，是把 AI 用在整条链路上，而不只是”扫描”这一步：找 bug、验证可利用性、生成补丁、协调披露。
Wiz 那边的细节也值得一提：他们用了 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol。其中 Gemini 4 Argon 在漏洞发现、漏洞利用开发、攻击检测和补丁验证四个环节上都发挥了”不可或缺的作用”。
看清楚这个描述——漏洞利用开发。也就是说，AI 在这里同时扮演了红队和蓝队。它得先能写出 exploit，才谈得上验证漏洞是否真实可利用，也才谈得上验证补丁是否真的堵住了。
这也是为什么过去两个月 OpenAI 一直在牵头协调。修 PHP 引擎底层的洞，改动面太大，随便发个补丁可能引发连锁问题。有 AI 参与补丁验证，这个流程才敢往下走。
但真正让我不舒服的，是 OpenAI 那句话
> “它们只是我们已经发现，并正在努力修复的众多重大漏洞中的一部分。我们未来几个月内类似的漏洞数量将急剧增加。”
我读了三遍。
这不是”好消息”，这是预告片。
翻译成大白话：AI 已经把一批还没修完的洞攥在手里了，接下来几个月会持续放出来。今天这个 PHP 的洞，是这个批次的第一次公开亮相。
现在你要在脑子里叠两个事实：
事实一：AI 找漏洞的能力，正在以远超人类修复能力的速度增长。
事实二：全球开源基础设施的维护，主要靠一小撮无偿或低薪的志愿者。
这两个事实一撞，结论不太好看：
漏洞发现的速度可以是线性的（甚至指数级，取决于你投多少算力），但修复的速度受限于人的注意力、代码理解深度、发布流程和向后兼容的顾虑。这个剪刀差，就是未来几年的系统性安全风险。
再看一层。OpenAI 说这次是”在攻击者之前为防御者打开了窗口”。
听起来很正面，但仔细想一想：这个窗口能开多久？
AI 找漏洞这件事，防守方能做，攻击者也能做。区别在哪里？
– 防守方要负责任披露：先找到、再验证、再写补丁、再协调、再发布。两个月起步。而且补丁还得向后兼容，不能把老用户的业务搞崩。 – 攻击者不需要披露：找到就用，直接用。
所以这个”防御者窗口”是真实存在的，但它极其依赖一个前提：防守方的 AI 能力必须领先攻击方一个身位，而且这个身位必须持续保持。
一旦 AI 找漏洞变成白菜价（现在是，将来更是），这个身位就会不断收窄。今天是 Open 领先，明天就是攻防同起跑线。
我真正想说的：别再只盯”AI 又立功了”
不出意外，网上的反应是这样的：还得是 AI 啊？AI 拯救世界了？
我不想泼冷水，但必须说两句。
第一，”AI 发现漏洞”这件事，本身不构成安全。 发现不是安全，修完才是。而这次 PHP 的洞，最尴尬的地方在于：它在 5.4 到 8.1 之间所有版本里都存在过，而这条版本带上有一大堆官方早就停止支持的版本。补丁根本不覆盖这些版本。
那些跑着 PHP 7.4 的公司——可能因为框架太老、可能因为成本、可能因为没人懂那套代码——明天依然裸奔。AI 帮不了他们。
第二，真正被 AI 改变的，不是”能不能找到漏洞”，而是”漏洞的生命周期”。
过去一个高危漏洞的平均生命周期可能是一两年（被发现、被利用、被曝光、被修复）。现在，随着 AI 扫描的铺开，这个周期正在被压缩到几个月甚至几周。
这对防守方意味着什么？意味着”定期打补丁”这个策略会越来越不够用。你打补丁的速度，永远赶不上漏洞被暴露的速度，因为暴露侧有 AI，修复侧只有你的值班工程师。
第三，PHP 这个案例暴露的是整个开源生态的结构性问题。
全球七成网站在跑 PHP，PHP 引擎的某个底层缺陷可以一次波及半个互联网。但这个语言的核心维护者有多少人？是个位数级别。
这是不匹配的。需求侧是几千万开发者，供给侧是十几个领工资的人。过去二十年这套体系勉强转着，是因为漏洞的发现速度也慢。
AI 把这个平衡打破了。
那该怎么办？说点实操的
我不是安全专家，但从工程落地角度看，有几件事现在就该做：
一、立刻确认你的 PHP 版本。 修复版本是 8.5.12、8.4.27、8.3.36、8.2.35。如果你在 8.1 或更早，先别想着”升级计划排期到下个季度”——这次真等不起。至少先把对外暴露的入口做隔离，能下线先下线。
二、优先检查 mod_php 部署。 官方明确说了 mod_php 风险最高。如果你还在用 Apache + mod_php 这种老架构，这是把它迁到 PHP-FPM 的最好理由——不是性能问题，是安全问题。
三、WordPress、Drupal、Joomla 这类 CMS 优先打补丁。 研究人员已经在这些部署上复现了未授权 RCE。这些系统往往跑着最不专业维护的那批站点，也是攻击面最大的一批。
四、别相信”没有外部暴露所以安全”这种自我安慰。 use-after-free 走的是请求级内存复用，内网应用一样中招。
五、把 AI 扫描加进你的安全流程，但别把它当银弹。 让 AI 找，让人来判，让流程来修。这三步缺任何一步，都只会变成噪音。
最后
这次事件的叙事很诱人：AI 英雄般地在攻击者之前发现了漏洞，拯救了地球。
但真相要复杂得多。
AI 不是英雄，它只是把整场游戏的节奏调快了。
漏洞被发现得更快了，漏洞被利用的工具更便宜了，攻防之间的时间窗口更短了。而人类这一侧的补丁流程、协调机制、维护者精力——一样都没变快。
这才是真正的挑战：当发现速度超过修复速度，安全就成了一场必然输掉的比赛。
今天这个 PHP 的洞，只是让所有人第一次在同一个时刻，把这场比赛看清楚。
接下来几个月，OpenAI 说要放出的那一批漏洞，会不断提醒我们这件事。
—
*漏洞编号：CVE-2026-109618 / CVE-2026-109619（统称 PHP2Shell）* *修复版本：PHP 8.5.12、8.4.27、8.3.36、8.2.35* *PHP 安全公告：https://www.php.net/index.php#2026-10-21-5* *Wiz 报告：https://www.wiz.io/blog/php2shell-php-rce* *OpenAI 协调披露说明：https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/*