挖洞 AI:一个十年老漏洞,两天被 AI 挖出来

2026 年 10 月 20 日下午三点左右，两个 CVE 编号开始在网上论坛和社交媒体上流传：CVE-2026-109618 和 CVE-2026-109619。

这是 PHP 基金会后来给出的官方复盘里的原话。它同时点明了两件事：编号是提前流出去的；随编号一起传出去的发布时间和 CVSS 评分都是错的——流传的版本写着 10.0，而真实评分是 9.2。技术细节没有泄露，一个字节都没有。

一天后，也就是 10 月 21 日，PHP 项目正式发布安全更新。这两个漏洞被统称为 PHP2Shell：一个未认证的远程代码执行，和一个 Heartbleed 式的进程内存泄漏。

先把这几个最硬的口径摆出来，因为它们决定了这次事件的量级。

受影响范围是 PHP 官方公告自己的表述：所有对外提供 web 请求的 PHP 安装，包括 PHP-FPM、Apache 加 mod_php、php-cgi、FrankenPHP 和 LiteSpeed。其中 mod_php 风险最高——官方原话是，有已演示的攻击路径可以在任何应用代码运行之前就触发它。

漏洞本身的名字很技术，但机制其实只有一句话：PHP 在处理请求的过程中如果发生致命错误，特别是内存耗尽，它清理请求状态时可能把没初始化完的数据当成有效数据来用；或者把已经释放的内存指针留到下一个请求去读。

Wiz Research 的技术分析把四个 bug 拆得很清楚。CVE-2026-109618 底下有两个：一是上传进度反序列化器的释放后重用，二是远程进程内存泄漏——攻击者甚至不需要应用调用 session_start，PHP 就能把回收内存的内容编码进 PHPSESSID 响应 cookie 里吐出来。CVE-2026-109619 底下也有两个：致命错误回溯的释放后重用，以及 OPcache 的类型混淆。

PHP 官方安全公告原文。公告把两个漏洞分别归类为「内存耗尽导致的状态损坏」和「过期的全局状态」，并逐条列出了受影响版本、升级方式，以及无法立即升级时的缓解配置项。

这里面有一句话值得单独拎出来：即使你跑的是一个 Hello World 级别的应用，只要用的是有漏洞的 PHP 版本，它照样中招。漏洞不在 WordPress 里，不在 Drupal 里，也不在任何插件里。它在解释器本身。

这一句的分量，要等到把时间线摊开才看得出来。

这个漏洞不是突然出现的。

2024 年，PHP 做了多年来第一次外部安全审计。审计由 Quarkslab 执行，PHP 基金会通过 OSTIF 从 Sovereign Tech Agency 拿到了资金来组织这件事。审计报告里列出的问题之一，在修的过程里被一位 PHP 核心开发者注意到了一个更深的线索——就是后来被编号为 CVE-2026-109618 的那个内存耗尽问题。

基金会自己的复盘写得很坦率：当时团队把这个 OOM 问题可能的利用方式推演过，但没找到具体的攻击向量；与此同时，审计报告里其他一些影响明确的问题把这个线索盖了过去。

接下来是两年里最难看的一段。

PHP 安全团队为这个 OOM 问题设计了好几套互相竞争的修复方案，每一套都有代价：向后兼容性会被打破；会引入新的拒绝服务面；或者需要大量第三方扩展配合改动，而这看起来根本不可能协调得成。团队在共识机制下反复权衡，也担心万一选错方案会引发连锁反应。

再加上一条现实约束：真正懂引擎内部、有能力做这种深度改动、并且有精力处理这个问题的核心开发者只有一小撮人，而且每个人都身兼多职。

基金会博客里有一句话，是整篇文章里分量最重的一句：

基金会官方复盘里讲 2024 年那次审计的那一段。原文承认：当时就已经推演过这个 OOM 问题可能的利用方式，但没有找到具体向量，问题因此被其他更明确的议题盖过。

这段自述比任何外部分析都更有价值，因为它把一件事讲清楚了：把一个漏洞挖出来，和让一个漏洞被修掉，中间隔着的不是技术水平，是组织的决策能力和人手。

而在 2026 年，这条链上的每一环都被改写了。

5 月，PHP 基金会成立了 Ecosystem Security Team，专门做分流、协调和加固。7 月和 9 月分别有两位新成员加入安全团队。与此同时，基金会和 Alpha-Omega 合作，用 Anthropic 的 Claude Mythos 扫描 PHP，后来又加进了 OpenAI 的 Daybreak Red 来验证报告和利用程序，再加上 sanitizer 构建和一套跟 CI 环境完全一致的复现环境。

AI 在这里不是来挖洞的，是来给挖洞的人干活的：验证报告、归并同一根因的报告、搭建复现环境。但最终每一条判断、每一个补丁，仍然由人来下、由人来做。

基金会在博客里提到了一个数字：7 月 1 日以来，安全团队发布了 15 个 CVE，同时处理了 100 多份被判定为无效、重复或无法复现的报告。以前一整年的报告量，现在几个月就涌进来。

所以时间线的真正拐点，不在 10 月 21 日，而在更早的地方。

PHP 基金会复盘里给出的发现阶段时间线是这样的。

7 月 30 日，OpenAI 把 PHP 项目纳入了它的 Patch the Planet 计划，安全公司 Calif 由此开始对 PHP 做审计。8 月 11 日，Calif 的研究员 Ryan A 上报了根因与 2024 年那个 OOM 问题相同的无条件远程代码执行。同一天，OpenAI 也独立上报了同一个根因。9 月 18 日，OpenAI 又报出了更多攻击向量。8 月 24 日，Wiz 上报。

Trail of Bits 后来也介入了审计。基金会特别写了一句：8 月 11 日起，修复这件事成了基金会全体安全工作人员的第一优先级。

8 月 11 日之后的两个月，是这次事件里最值得看的部分。因为它把一个通常被忽略的事实摆到了台面上——同一个漏洞，是被至少三支互相独立的队伍各自挖出来的。

Calif 是 OpenAI 计划下的合作方，用的模型包括 GPT-5.6 Sol。Wiz 用的是自家的 Wiz Atlas，加上 Gemini 4 Argon 和 GPT-5.6 Sol。OpenAI 自己也有一支团队在做同样的事。Wiz Research 在官方博客里写得更直白：他们用 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol 贯穿整个研究，其中 Gemini 4 Argon 在发现漏洞、开发利用程序、攻击检测和验证补丁这四件事上都做出了关键贡献。

Wiz 给这段过程下了一句定义：这些漏洞的代码已经存在超过十年。要把它们变成能跑的利用程序，需要串联多个 bug，并且针对每个目标的内存布局反复测试调试。在 AI 之前，这部分手工工作很难实现，更难规模化。

然后是那句关键的话：

Wiz Research 官方博客里讲 AI 拐点的那一段。原话是：有了 AI 这已经不再是一道障碍，大模型可以帮助把利用程序适配到不同的 PHP 版本、配置和内存布局。

这段话里有一个词值得注意：适配。

内存类漏洞最麻烦的地方从来不是找到它，而是证明它可用。你得让利用程序在特定的内存分配方式上跑通，而这个分配方式取决于 PHP 版本、编译选项、扩展组合和应用的具体行为。打一个目标成功，换个目标可能要重新调半天。在 AI 之前，这个调参过程本身消耗的是专家的工时。

Wiz 的博客里还有一句更值得被引用的判断：随着这项工作所需的时间和专业门槛下降，复杂度本身不再构成有意义的屏障，这会改变我们对什么叫做实际可利用的定义。

这句话是整个事件的题眼。

发现得快是一回事，能打出远程代码执行是另一回事。这两个时间尺度被很多人混着讲，实际上分开看更清楚。

7 月 30 日，Calif 开始审计 PHP，8 月 1 日就摸到了触发上述漏洞之一的入口。从开始审计到摸到门，两天。（基金会复盘只给了 7 月 30 日和 8 月 11 日这两个节点，8 月 1 日这个节点来自对外披露的完整时间线。）

8 月 11 日，完整攻击链上报。8 月 19 日，Wiz 用 Atlas 加 Gemini 4 Argon 和 GPT-5.6 Sol 找到了自己的第一个 bug。8 月 20 日，Wiz 就拿到了针对 Drupal 的未认证代码执行；8 月 21 日，对 WordPress 也打通了。

Wiz 后来在自己的博客里，把这两天的成果描述为把漏洞变成武器的过程。他们把这几个利用程序合并成一个脚本，命名为 php2shell，在 WordPress、Drupal 和 Joomla 的最新容器镜像上成功演示了无需认证的远程代码执行。

这两组时间数字放在一起看，才是这件事真正的冲击力所在：

Wiz Research 官方博客里的漏洞对照表。四个可利用的 bug 被归入两个 CVE：上传进度反序列化器的释放后重用、远程进程内存泄漏、致命错误回溯的释放后重用，以及 OPcache 类型混淆。

漏洞在代码里躺了十四年，其中至少两年被明确知道有蹊跷却修不动。然后 AI 来了，两天摸到门，两天打通执行。

而从发现到修复，花了两个月。

这个反差，是这篇文章真正要讲的东西。

OpenAI 在披露公告里给出了一个专门的概念，翻译成中文大概是防守方窗口。

它背后的逻辑是这样的：如果前沿 AI 比攻击者更早发现了这些漏洞，那么维护者和安全厂商就获得了一段准备时间——可以在漏洞公开之前把补丁、规则、检测手段全部准备好。OpenAI 在公告里的表述是：据我们所知，前沿 AI 比攻击者更早发现了这些漏洞，为维护者和安全服务商打开了一个防守方窗口。

这个窗口的宽度，用这次的数字来量是有说服力的。Cloudflare 是最早动手的防护方之一，它的博客说从 2026 年 10 月初就开始开发 WAF 防护，规则部署在公开披露前大约 9 小时上线。10 月 21 日凌晨 3 点 02 分开始，所有使用 WAF 的 Cloudflare 客户——包括免费用户——默认获得保护。

同时还有一整串名字在行动：Akamai、AWS、Fastly、Imperva、Microsoft、Automattic、Vercel、Google Cloud。Wiz Research 说，这些合作方在公开披露前和他们一起准备了客户指引、检测规则和开箱即用的缓解措施。

这就是防守方窗口在纸面上的样子：一群防守方在漏洞公开前就已经把防线铺好了，公开那一刻不是从零开始，而是从有准备的姿态接敌。

Cloudflare 的 CEO Matthew Prince 在社交平台上给了一组数字：公开前的 10 个小时里，Cloudflare 网络上已经看到数千次尝试；公开后 45 分钟涨到数万次，2 小时内到数十万次，之后进入百万量级。

一个补丁能在公开前铺到免费用户的边缘节点上，这本身就是过去很难想象的事——不是防守方跑得比攻击者快，而是防守方提前把规则准备好了。

Cloudflare 官方博客。左边是它对两个漏洞的通俗解释，右边说明了防护的具体形态：免费用户 7 条规则、付费用户 7 条规则、全部计划再加 1 条高置信度的响应侧规则，默认开启。

但这个窗口在这次事件里，同时被另一个方向的力量压着。

协调披露有一个前提：所有参与方都要守静默期。而这次静默期被撕开了三次，每一次都出自参与方自己。

第一次，10 月 20 日下午三点左右，两个 CVE 编号和错误的评分流传到论坛和社交媒体上。技术上没泄露，编号本身也不算敏感，但发布节奏被打乱了——厂商的补丁分发节奏是按原定时间排的。

PHP 项目的应对是把预公告提前到当天 19:30 发布，同时把正式发布从 10 月 22 日 14:00 提前到 10 月 21 日 14:00。基金会给出的理由很实在：发行商当时还在打包修复，如果立刻发布，很多人会没有方便的更新途径。往前挪一天，是在行动速度、给用户准备时间、和确保大家都有简单升级路径之间做的折中。

第二次，同一天晚上 20 点左右，Calif 误发了一段视频。视频里他们的概念验证程序正在多个目标上运行，暴露了一部分虽然有限但确实存在的技术细节。视频很快被删，但副本开始到处传。基金会的判断是：这段视频加速了各种概念验证程序的开发，进而加剧了 10 月 21 日的流通。

第三次，也是最关键的一次。10 月 21 日 07:41，也就是协调发布前六个多小时，Chainguard 单方面破坏了静默期，发布了包含修复的构建镜像。Chainguard 和其他发行商一样提前拿到了补丁，本意是让用户能在披露瞬间就更新。但镜像一旦公开，任何攻击者都能立刻研究这个二进制形式的补丁，而其他所有 PHP 用户还在等发布。

基金会在复盘里的评价是一句重话：这无视了多方数周以来为协调披露所做的工作。

基金会官方复盘里专门讲泄露与披露被打乱的那一段。原文记录了三次来自参与方自身的静默期破坏，以及项目方两次调整发布时间线的应对。

所以防守方窗口这件事，在这次事件里其实是双向的。

往一边看，前沿 AI 确实替防守方抢到了时间——Cloudflare 提前 9 小时上线规则，成千上万家使用 WAF 的客户在那 9 小时里已经是被保护状态。往另一边看，参与方自己的操作失误在最后关头把这段时间又削掉了一部分，还额外制造了一批本来不该出现的攻击面。

还有一个更早的信号，来自攻击方那边。

亚马逊的 MadPot 蜜罐网络在 10 月 17 日记录到了一次针对 PHP2Shell 的利用尝试。那是协调披露日之前四天。

亚马逊自己的表述很谨慎：这个活动是在漏洞处于静默期时发生的，蜜罐被一个匿名 IP 定位，这说明是某个真实的威胁行为体干的，但攻击者是怎么在公开之前拿到利用信息的，仍然不清楚。

亚马逊还提到另一件事：10 月 21 日当天，他们检测到多个概念验证利用程序，最早出现在凌晨 2 点左右，比补丁发布早了大约 12 个小时。之后六小时里，来自不同匿名基础设施的尝试陆续出现，用了各种不同的载荷形式。亚马逊认为这指向多个攻击者，而不是单一团伙。

这些数字对防守方窗口的判断影响很大。如果漏洞公开前四天就有人在打，那么所谓窗口，在最关键的那一段其实是不存在的。

不过这里有一个必须说清楚的口径差别：PHP 基金会和 Wiz 在披露时都明确表示，他们没有发现可用的、可运行的完整利用程序。Wiz 的后续追踪文章写得更细——他们观察到了两个开源利用工具包的变体，其中旧的那个撞上了请求大小限制，新变体确实能稳定耗尽 PHP 内存，但每次都拿不到继续下去所需的内存地址，两者都没能在他们抓到的尝试里完成利用链。

也就是说，截至他们发文的时点，攻击者手里有工具，但没有一把真正能开门的钥匙。而防守方这边，已经有补丁、有 WAF 规则、有检测规则、有下线指令。

这一局防守方是赢的，但赢得很勉强。

10 月 21 日同一天，NSA 和 CISA 都发了正式通告。

NSA 通告里的措辞很不含糊：网络行为体很可能会武器化 PHP2Shell 漏洞。这些风险严重到需要美国政府各部门和机构立即打补丁。通告给了一条在常规安全建议里很少见的建议——如果没办法立刻更新，建议把系统下线，直到能完成缓解为止。

CISA 告警的口径更具体，也更严格。组织如果无法立即更新，或者继续使用 PHP 8.1 及更早的、已经停止安全支持版本，应当把基于 PHP 的系统下线，直到能打上补丁。CISA 明确说明这些漏洞允许未认证远程代码执行；PHP 官方公告另外列出了拒绝服务和数据暴露。

CISA 官方告警的处置建议部分。除了要求盘点全部 PHP 安装并优先处理面向互联网的系统，还明确写着：无法立即更新的组织应当把系统下线，直到能完成补丁；WAF 只能提供部分保护。

这里有个绕不开的事实：PHP 官方公告写明，PHP 8.1 及更早版本不再从项目获得更新。安全团队只是为 7.4、8.0、8.1 提供了最小化的源码回补，用来帮助那些自己从源码构建、或者没有 LTS 厂商可用的用户。

也就是说，受影响面里最大的一块——那些跑着老版本、装在自己机器上、连个像样的运维都没有的站点——没有官方补丁可打。

对这部分资产，NSA 和 CISA 给的答案不是修，是关。

Wiz Research 后来公布了一组追踪数据：公开披露后，他们记录的每日暴露在互联网上的易受攻击主机数量下降了大约 67%；有至少一个暴露且易受攻击实例的组织数量下降了大约 47.9%；在易受攻击主机里，跑 PHP 7.3 及更早的比例在五天内从 8.3% 降到 5.7%。他们也给了个横向参照：他们数据集里有 65% 的组织在用 PHP。

Wiz Research 披露后一周的追踪数据。暴露主机数下降约 67%，受影响组织数下降约 47.9%，跑 7.3 及更早版本的比例从 8.3% 降到 5.7%。

这个数字值得停下来看一眼：将近一半的受影响组织，在一周之后仍然暴露着。

剩下的那部分里，很大一块是上面说的老版本用户——他们的选择本来就不多。要么升级，要么用回补，要么下线。

还有一件事必须讲清楚，因为它是这次事件里最容易被误读的一块。

关于到底有多少台机器受影响，现在流传着好几个数字，口径各不相同，混用会得出完全错误的结论。

第一个是 70%。这是 Wiz Research 官方博客里的表述：PHP 驱动着全世界 70% 的网站。这个数字被大量二手转述引用，但它是一个估计值——W3Techs 同期的口径是「服务器端语言已知的站点里 69.3%」，Cloudflare 写的是「将近 70%」，三家说的其实是同一件事的不同切片。

第二个是 3300 万。这个数字来自 Censys 的面板：仍有约 3350 万个暴露的 PHP 服务跑在受影响版本上。它的口径是「服务」，不是站点、也不是服务器——Censys 自己写明这三者之间不能直接换算，一台服务器可能同时跑多个服务。

第三个是 2260 万。这是 Palo Alto Networks 的 Unit 42 基于自有遥测估出的「潜在受影响的暴露实例」数，和站点数不是一回事——一台服务器上可能跑几十个站点，一个站点也可能只在特定路径上触发。

这三个数字之间的换算关系并不自洽，引用的时候必须说清楚是谁在什么时间用什么方法测的。任何一个不带出处的裸数字，都不该被搬进稿子里。

但真正值得关注的不是这些总量数字，而是它们的分布。

PHP 官方公告的风险描述里有一句话点出了问题的形状：所有对外提供 web 请求的 PHP 安装都有风险，其中包括 PHP-FPM、Apache 加 mod_php、php-cgi、FrankenPHP 和 LiteSpeed。

Sysdig 的创始人洛里斯·德焦瓦尼在采访中把这层意思说得更透：每个 PHP 应用都暴露在威胁之中，包括那些公司自己在资产清单上都没记录的供应商门户、管理后台和被遗忘的营销网站。

更麻烦的是那些连 PHP 都不太被当成互联网一部分的地方。PHP 不只是跑网站，它还大量嵌在工业网关、楼宇管理系统、家用路由器和网络存储设备里，而这些地方的更新周期常常以年计。Help Net Security 在报道里引用安全研究者的判断，说有太多被遗忘、没人维护的应用永远不会被打补丁，这次危机会拖出一条很长的尾巴。

所以这次的暴露面形状，不是「一个 popular 语言的所有用户」，而是「一整片没人负责的资产」。

基金会博客的最后一段，是这篇复盘里最不像技术文章的一段。

它的核心意思是：PHP 跑着整个互联网很大一部分，包括政府服务、网店、银行、媒体站，以及企业每天依赖的诸多软件。但 PHP 自身的安全工作，仍然只靠基金会里一小群人。

文章结尾在向使用 PHP 的公司、主机商、云平台和政府要赞助。

这不是客套。OpenAI 在同一时间的披露公告里宣布，通过面向一线防御者的 Daybreak 计划，提供价值 10 亿美元的 Daybreak 使用补贴，重点支持安全资源有限、承担关键服务防护职责的组织。它同时发布了一个免费的 PHP 版本检查工具，做成 Codex 技能的形式放在 GitHub 上，让运维人员先识别自己跑的是哪些版本，再决定是打补丁还是下线。

OpenAI 还把这套应对拆成了五步框架，作为给社区的通用建议：第一，验证并修复上游漏洞；第二，给受影响的组织留出应对时间；第三，与政府伙伴协调响应；第四，为受影响的产品和服务准备好更新；第五，发布指导并支持防御方落地。

把这两件事放在一起看，就出现了一个很不对称的结构。

发现漏洞的成本，刚刚被 AI 压到了接近于零。Calif 两天摸到门，Wiz 两天打通利用，OpenAI 独立复现同一条根因——三支队伍同时到达。

而修复漏洞的成本，一点都没降。

PHP 基金会的 2024 年审计已经发现了问题的最初迹象，2026 年 8 月才拿到可用的攻击路径，中间是因为决策机制和人手不足而反复停摆。10 月 21 日发布补丁之后，PHP 8.1 及更早版本依然没有官方更新，最老的那批站点只能下线或者自己编译最小回补。

OpenAI 自己也知道这个不对称。它的公告里有一句预警：我们预计未来几个月类似发现将大幅增加。

它同时给出了一个条件，说得比谁都清醒：据我们所知前沿 AI 比攻击者更早发现了这些漏洞，打开了防守方窗口——但这个窗口是有条件的，它依赖于防守方手里的模型能力明显领先于攻击者普遍能拿到的能力。

一旦攻防双方用的是同一批模型，这个窗口就会收窄。这是这次事件给出的最硬的一个前瞻。

该给这件事一个准确的定性了。

它证明的事情很硬。

第一，一段存在了超过十年的、连专家都难以判断可利用性的内存管理代码，可以被 AI 在两天内变成能打出未认证远程代码执行的武器。Wiz 的原话是，这件事的门槛已经不再是门槛，复杂度不再构成有意义的屏障。

第二，一个跨语言、跨厂商、跨国家的协调披露机制，在压力下是可以跑起来的。Cloudflare 在公开前 9 小时把规则推到包括免费用户在内的全部客户；Akamai、AWS、Fastly、Imperva、Microsoft、Automattic、Vercel、Google Cloud 各自准备了指引和缓解措施；NSA 和 CISA 发了正式通告；OpenAI 提供了 10 亿美元补贴和免费的版本检查工具；PHP 基金会还提前为 7.4、8.0、8.1 做了最小源码回补。

第三，它把防守方窗口这个概念从纸面变成了可测量的东西。补丁分发、WAF 规则上线、检测规则就位、政府通告、版本自查工具——这些环节以前是各自为战的，这次被压进了同一个时间轴里。

而它没有证明的事情同样清楚。

它没有证明攻击还没开始。亚马逊的蜜罐在 10 月 17 日就抓到了利用尝试，比公开披露早四天。Wiz 也说了，有伙伴私下向他们披露过能对多种目标生效的利用程序。窗口开着的时候，外面已经有人拿着放大镜在看。

它没有证明防守方窗口会一直开着。OpenAI 说得很清楚，这个窗口依赖于防守方的能力领先。当攻防双方用的是同一批前沿模型，窗口的宽度就会由能力差距决定，而能力差距会自己收敛。

它更没有证明修漏洞这件事变容易了。基金会写下的那句话就是答案：发现成本塌了，修复成本没动。这两者之间的落差，会变成下一个问题的形状。

还有一件事值得说。PHP 基金会在这篇复盘里，做了一件很不寻常的事——它没有回避自己在 2024 年的失职，也没有把功劳都推给合作方。它明确承认那次延迟是结构性失败，承认静默期被撕开三次是自己人干的，甚至点名了哪一个环节自己判断错了、哪一个环节本意是好的但造成了伤害。

一份漏洞复盘愿意这样写，比漏洞本身更值得看。

回到那个最初的账。

这次的账其实是三本。

第一本是技术账。从 8 月 11 日上报到 10 月 21 日发补丁，两个多月，三个未认证远程代码执行（两个 CVE，CVSS v4 均为 9.2），外加一个能读出密码、令牌、API key 和证书的内存泄漏。这本账已经结清了——补丁发了，规则上了，公告发了。

第二本是协调账。这本账还没结清。三次静默期破坏，其中一次是提前六小时公开了补丁的二进制形式；两次时间线被迫调整；一次在野利用早于披露四天。这本账要结清，得改的不是技术，是协调披露的规则本身——谁有权在什么条件下打破静默期，打破之后怎么收场。OpenAI 在公告里提到了一个建议社区讨论的框架，但那是下一步的事。

第三本是钱。发现漏洞的人变多了，修漏洞的人还是那几个。基金会 7 月 1 日以来发了 15 个 CVE，处理了 100 多份无效报告，而做这些事的是一小撮核心开发者。OpenAI 的 10 亿美元补贴能解一时，但它是补贴，不是结构。

OpenAI 提到了「修补地球」这个计划，也提到了给 Rust 基金会这类项目的直接赞助。这暗示的思路很清楚：当发现漏洞这件事变得极其廉价，防守方的稀缺资源就该从「找漏洞的人」转移到「能立刻改代码、能立刻发补丁、能立刻验证补丁的人」上。

所以接下来真正该盯的，不是下一个被 AI 挖出来的高危漏洞，而是三个更慢的指标。

PHP 基金会在博客最后说的那句话，其实是对整个行业的一个提问：现在找漏洞的人太多，而修漏洞的人太少。

AI 让找漏洞这件事从一种需要多年积累的手艺，变成了一次可以外包给智能体的任务。于是新的瓶颈浮出水面了——不是没人能发现问题，是没人能改。

一个能自动找出十年老洞的系统，配上一个只有几个人的维护团队，这个组合的产出速率，取决于最慢的那一环。

而这一次，最慢的一环还是人。

— END —

洞见智能浪潮 · 探寻未来之道