2026年10月21日，如果你那天在荷兰、芬兰或者丹麦，打开政府网站、医院预约系统，甚至维基百科，看到的可能不是页面，而是一堵墙。荷兰国家网络安全中心把自己的官网撤了下来，鹿特丹港、荷兰足协、五大政党的网站跟着下线，丹麦关掉了全国学校的通讯平台，芬兰政府把所有对外的网络服务临时切断。法国内政部更干脆，让所有省政府网站进入“维护模式”。英国也有超过30个政府服务临时下线。
这不是黑客打进来了。这些网站是自己主动关掉的，因为一个在PHP代码里潜伏多年的漏洞突然被AI挖了出来，而修补它所需要的“确定性”，没有人敢用在线时间来赌。 据当时的公开报道，这被广泛描述为第一次有AI发现的漏洞促使多个国家在同一天主动下线政府服务。但真正让这件事值得写下来的，不是“AI又赢了”这个标签。真正扎心的地方在于：这个漏洞一点都不新。它被人摸到过、报告过、审计过，然后被所有人默契地放过了。
它叫PHP2Shell，但它真正的名字是“算了，太累了”
PHP官方按CVSS v4.0给这两个漏洞的评分是9.2(满分10)，安全公司watchTowr直接给了满分。从技术上说，问题出在PHP引擎处理内存耗尽和请求收尾的方式里。一个漏洞出在内存耗尽时的跳出路径上：请求在初始化还没完成时就被中断，清理阶段踩到半初始化的状态。另一个则是请求结束后，常驻进程的记忆里还留着已经释放的指针；下一个请求路过时踩上去，就可能被利用来在服务器上执行代码。攻击者不需要登录，不需要通过应用的路由，只需要构造一个让PHP引擎在“收尾那几毫秒”出错的HTTP请求。
但把时间线拉长，这个故事完全变了一个味道。可查证的历史线索指向至少两处被搁置的痕迹：2020年，一份PHP bug报告涉及multipart请求下触发内存耗尽和临时文件未清理的问题，几乎没人理会；2024年，OSTIF资助、Quarkslab执行的PHP首次外部安全审计重新碰到了同一类OOM问题，但因为未能证明“真的可以被利用”，修复被搁置。PHP核心开发者在处理其他问题时也触及过同一苗头，修复方案因兼容性和扩展协调问题反复停滞。
安全圈后来用“security by exhaustion”来概括这种状态——靠攻击者累到放弃来保证安全。把这种内存层面的漏洞做成能稳定工作的攻击链，往往需要数周枯燥的手工调试。过去多年里，没有人愿意为它付这个成本。所以它一直“安全”，不是因为修好了，而是因为利用它的性价比太低。
AI改变的不是漏洞的存在，而是这个性价比。当机器可以不知疲倦地在内存布局里试错，把过去需要数周手工打磨的利用链压缩到更短的时间窗口，“累到懒得修”就不再构成一道防线了。 而当这个成本被压下来之后，接下来发生的事，几乎是一场被泄露拽着跑的应急。
48小时，一条被从中间撕开的披露时间线
按照安全行业的惯例，软件方先把补丁准备好，再和发现者协调公开。这一次，补丁还没准备好，时间线就从中间被拽断了。
2026年8月，研究员Ryan Austin通过“Patch the Planet”项目使用AI模型首先发现漏洞，8月11日向PHP基金会报告；Wiz于8月19日独立发现，8月24日报告。原定的公开日期是10月22日。但10月20日，关于两个CVE的信息出现在Hacker News和地下论坛上，watchTowr当天确认漏洞为真。PHP官方紧急把补丁发布从22日提前到21日14:00 UTC。更致命的事情发生在补丁之前：一份PoC视频被误发后迅速扩散，收不回来了。
于是出现了一个在漏洞披露史上相当罕见的错位：Cloudflare的CTO在补丁发布前近六个小时，就已经公开表示已看到早期攻击出现。亚马逊后来的复盘更加冰冷：最早的利用尝试出现在10月17日，也就是公开披露前四天，来自匿名网络，而且参与的黑客不止一人。
Cloudflare CEO Matthew Prince在X上留下了一组数字，几乎是一张攻击烈度的心电图：公开前10小时，数千次尝试；公开后45分钟，数万次；2小时内，数十万次；到第二天早上，Cloudflare网络观测到的尝试达到数百万次。Censys在21日统计，仍有约157万台暴露在公网的PHP主机没有完成修复；VulnCheck另称至少100万台运行在已经停止支持、根本拿不到官方补丁的旧版本上。
Forescout威胁追踪高级经理Sai Molige把这件事和Log4Shell放在了一起，说它可能演变成“Log4Shell规模”的事件。但他指出了一个PHP场景下更麻烦的地方：Log4Shell的难点在于找不到哪些系统用了那个组件；而在PHP这里，就算你找到了，很多机器上的版本已经老到官方不再管了。
为什么“下线”不是恐慌，而是一道冷静到近乎残酷的选择题
补丁和攻击几乎同时到达，这就解释了为什么多国政府的选择不是“等等看”。多国网络安全机构给出的建议这次罕见地一致，但措辞很克制：先打补丁。如果打不了，把系统从互联网上摘下来。 CERT-EU和英国NCSC的指引里，下线不是首选，而是无法修补时的隔离手段。荷兰、芬兰、丹麦、法国那些机构做的，就是在修补窗口被PoC泄露压缩到以小时计的情况下，用可用性去换确定性。
一个容易被忽略的细节是，这个漏洞的利用痕迹天然贴近“正常失败”。在受影响版本和已经打上补丁的版本之间，一个触发内存耗尽的请求在HTTP响应层面可能几乎看不出区别——两边都可能干净地报出“Allowed memory size exhausted”，应用日志里不会出现一行写着“攻击成功”的字。德国BSI将风险定为3/橙色(“异常高”)；在公开层面，至少没有看到已确认成功入侵的官方说法。
这并不意味着风险被夸大了。它意味着这件事的危险之处恰恰在于：一场可能已经发生了部分利用的攻击，在常规监控里可能什么都没留下。SentinelOne的分析指出，这条利用路径的内存泄露阶段不在主机上执行代码，没有进程行为可供传统EDR捕捉，信号只能从Web服务器、WAF和CDN的遥测里去捞。换句话说，你不知道它有没有成功，是因为你本来就没有在“那个层面”看着它。
既然痕迹这么淡，排查就不能只等告警。可操作的线索集中在少数几个方向：Web服务器错误日志中异常聚集的“内存耗尽”致命错误及其源IP；PHP进程出现非预期的启动shell或下载文件行为；以及面向互联网的PHP服务器上新增的异常文件、计划任务或账户。这些线索的前提是，组织此前已经建立了日志基线。 如果此前没有，事后回溯的难度会显著上升。
这件事真正留下的，不是又一个要打的补丁
对于还在运行PHP的组织，操作层面的结论其实非常短：升级到8.5.12、8.4.27、8.3.36或8.2.35，然后重启PHP-FPM、Apache以及所有常驻worker进程。不重启，旧进程还在跑旧代码，补丁等于没打。跑在8.1及更早版本上的，官方已经不提供修复了，唯一的出路是迁移。
但比补丁更值得记住的，是那个“多年没人愿意修”的事实。一个漏洞之所以能在代码库里躺那么久，不是因为没有人看见它，而是因为看见它的人算了一笔账：把它变成武器太费劲了，不划算。 AI没有凭空创造出一个新漏洞，它只是把“不划算”这件事，从攻击者那一侧拿走了。
下一次，当某个漏洞被标注为“利用复杂度高”的时候，那个“高”字的保质期，可能比我们习惯的要短得多。
