PHP2Shell 之后：AI 加速漏洞利用，补丁窗口正在消失

关闭通知

本文也有英文版。

本文在技术协助下翻译，并在发布前经过编辑审校。

.

连《每日新闻》和各大报纸都报道了：两个严重的 PHP 漏洞曾一度让互联网的大片区域陷入瘫痪。在此过程中，安全研究得到了人工智能的大力支持。但真正有意思的并不是漏洞本身。这个案例更多说明的是，未来从安全更新发布到被利用之间可供利用的时间恐怕会少得可怜。对于维护不善的软件来说，这正日益成为一个问题。

广告之后继续阅读

Tobias Glemser 是 BSI 认证的渗透测试人员，也是 secuvera GmbH 的总经理。他在网络安全领域工作已超过 20 年。业余时间，他还参与 OWASP 等组织的工作。

10 月 21 日，德国大量网站和在线服务无法访问。政府部门、高校、医院和企业纷纷预防性地将系统下线。联邦信息安全局（BSI）的门户网站也一度受到影响。原因是 PHP 中的两个严重漏洞，而 PHP 是全球使用最广泛的 Web 应用编程语言之一。

漏洞 CVE-2026-109618 和 CVE-2026-109619 在特定条件下允许在受影响服务器上执行任意程序代码，且攻击者无需事先通过身份验证。其影响可能相应地十分严重。

尽管如此，这类漏洞本身起初并不算全新事物。内存管理错误、释放后使用（use-after-free）漏洞和远程代码执行，我们已经认识了几十年。广泛使用的软件中出现严重漏洞也不是新现象。

那么为何如此轰动？又为何有如此多的运营方不得不关停他们的系统？

答案与其说在于这两个漏洞本身，不如说在于如今漏洞被分析和利用的速度已经改变。

从已知错误到严重问题

广告之后继续阅读

前史早在 2024 年就已开始。在一次外部安全审计后，一名 PHP 开发者发现了内存管理中存在错误的迹象。当时就已经在考虑可能的利用方式，但起初无法加以证实。要是放在 2026 年夏天，情况又会如何呢？

修复工作被搁置了。各种解决方案在兼容性和稳定性方面都有缺点，有经验的开发者又忙于其他任务。PHP 基金会如今自己也称这一拖延是结构性失误。直到 2026 年 8 月，Calif、OpenAI 和 Wiz 等机构借助 AI 证明了具体的攻击可能性之后，优先级才骤然改变。安全更新最终于 10 月 21 日发布。

这里已经暴露出我们以往处理安全漏洞方式的一个弱点：某个漏洞没有已知的可利用代码，并不意味着它无法被利用。这首先只意味着我们目前还不知道有这样一种利用方式。

披露：组织良好——却仍然出了岔子

最初的协调工作出奇地顺利。安全研究人员、PHP 开发者、发行版和基础设施运营方通力合作，使得 Cloudflare 等机构甚至在安全更新发布之前就能启用防护措施。考虑到 PHP 的普及程度，这是一项了不起的成就。

10 月 20 日，首批信息提前泄露。PHP 团队随即把原定于 10 月 22 日的发布提前了一天。此外还有一段意外发布的漏洞利用视频，以及在禁运期结束前就已提供的修正版容器镜像。潜在攻击者因此得以在官方更新全面可用之前就研究这些改动。据亚马逊称，其蜜罐基础设施甚至在 10 月 17 日就观察到了利用尝试。攻击者究竟是如何在发布前就获得必要信息的，目前尚不清楚。

补丁成了攻击者的指南

AI 一如既往是福也是祸。Wiz 的研究人员描述了如何借助 AI 支持开发出复杂的攻击方式。据其自述，一名研究人员在大约一周内就能完成过去需要专门团队耗时数月的工作。当然，这类说法应当谨慎看待。但基本趋势显而易见：一旦安全更新发布，攻击者就可以把修正后的软件与之前的版本进行比较。这种补丁差异分析（Patch-Diff-Analyse）绝非新事物。多年来它一直被用来查明厂商通过其改动修复了哪些错误。可以说，补丁标出了应当查找的位置。

以往，要由此推导出真正可利用的漏洞需要大量经验和时间。尤其是在复杂的内存错误中，开发可靠的漏洞利用代码可能耗费巨大精力。

但如今令人担忧的是，至少在中短期内，任何不具备高深专业知识的攻击者都能在短时间内开发出可用的漏洞利用代码，并大规模地“铺开”。对攻击者来说，这门生意变简单了。对防御者来说，时间变得更紧迫。紧迫得多。

由此，我们漏洞与风险管理的一项根本基础正在改变。

半个互联网进入维护模式？

根据监测服务商 UptimeRobot 的测量，该服务所监控的 .de 网站中无法访问的数量在 10 月 20 日至 21 日期间上升了约 113%。在欧洲测量点，高峰期记录的宕机警报数量约为平时的二十倍。并非所有这些故障都能归因于 PHP2Shell。

在德国，众多公共机构预防性地将各自的服务下线。受影响的有州级行政部门、市镇、高校和医院。企业也做出了反应：发票软件供应商 easybill 同时关闭了其应用和网站。托管服务商 D&T Internet 的部分老旧应用导致无法进行短期更新，因此系统不得不迁移到其他服务器。

这带来了重大的经济后果。在线商店在停运期间失去下单渠道，客户无法使用云应用，政府部门也无法提供数字服务。当然，在许多情况下，预防性地关停受威胁的服务是正确的，尤其是官方更新直到 10 月 21 日才准备就绪。尽管如此，我们仍应深思：面对一个严重漏洞，我们数字基础设施的一部分实际上只能在带重大风险继续运行与直接关停之间做选择。这不能成为长久的解决方案。

软件维护不善的代价

说到这里，我们要谈一个在关于令人印象深刻的 AI 能力的讨论中有些被忽视的问题。

维护不善的软件终究还是维护不善的软件。

多年来我们一直见到这样的应用：它们运行在过时的 PHP 版本（或其他软件）上，使用不再受支持的库，或者其厂商早已不再提供更新。它们被委婉地称为“遗留应用”：业务关键，因此仍在线运行，但已无法维护。原因多种多样：更新可能影响功能，迁移需要花钱，最初的开发者已不在，或者没人愿意为较大的改动承担责任。

于是更新被推迟。下一次又推迟。由此形成一个补丁缺口，导致更大的“不可维护性”。

只要不出事，这种策略似乎还行得通。毕竟应用还在运行。为什么要投资于一个显然已经履行其用途的东西呢？

答案我们现在（再次）看到了。

这事我们不是已经经历过一次了吗

还记得 2021 年 3 月的人，大概会有似曾相识之感。当时是 Microsoft Exchange 中的四个严重漏洞，以 ProxyLogon 之名广为人知。在攻击者组织 Hafnium 已经利用这些漏洞之后，微软发布了计划外的安全更新。当时《每日新闻》和各家报纸也做了报道。

德国联邦信息安全局（BSI）称德国有数万台可通过互联网攻击的 Exchange 服务器，并直接致信了 9000 多家企业。当时我在补丁日过后不到一周做了一次小分析：所选服务器（均来自员工超过 1000 人的组织）中有 50% 仍未打补丁。现在情况好些了吗？人们有理由怀疑。

当然，Hafnium 和 PHP2Shell 的经过并不相同：Exchange 漏洞在更新发布之前就已被成功利用。两者的相似之处在于运营：补丁流程存在缺陷。

那么现在呢？

从理论上说，对 IT 运营的要求历来都是一样的。然而，落实补丁的时间窗口正在急剧缩短。仅仅把安全更新的责任归到某个 IT 部门是不够的。企业必须知道哪些系统是业务关键的、它们依赖哪些软件组件，以及如果这些系统必须在旦夕之间关停会发生什么。正因如此，才需要一套有效运转的信息安全管理和业务连续性管理。

但 AI 也会帮助防御方发现漏洞、检查修正并迅速铺开。

2021 年的警报叫 Hafnium，2026 年的叫 PHP2Shell。

到现在还没听到枪声的人，下一次大概也听不到。不打补丁不是选项。

（odi）