PHP2Shell 事件只是预演：AI 找漏洞的速度已超过维护者修复速度

席卷网络的最严重安全恐慌之一正在造成大范围混乱，促使企业、医院、学校和政府机构在竭力保护自身免受PHP两个严重漏洞影响的同时，暂时关闭网站和在线服务。PHP是支撑互联网大部分内容的编程语言。

这两个漏洞被统称为PHP2Shell，可能让未经身份验证的攻击者在受影响的服务器上执行恶意代码。大型科技公司一直在争分夺秒地保护用户：Cloudflare部署了防火墙防护，Automattic确认其各平台托管的网站——包括WordPress.com、WordPress VIP和Tumblr——已经得到加固。与此同时，维基媒体基金会将多项辅助服务下线，直到它们能够被打上补丁。

PHP项目周三为8.2至8.5版本发布了紧急修复。更早的版本已不再获得官方支持，尽管一些发行版和供应商提供旧版修复，PHP也为7.4至8.1版本发布了有限的补丁。

然而，尽管PHP漏洞本身就是一件大事，围绕其发现、修复和披露的情况却揭示出开源社区日益增大的压力，因为AI让发现严重安全缺陷变得更容易。

“在PHP中寻找糟糕的漏洞”：提示词发现

即将发布补丁的消息在周二传出，此前相关细节在预定披露之前遭到泄露。第二天，OpenAI透露，安全公司Calif使用其GPT-5.6 Sol模型发现了其中一个漏洞，而谷歌旗下的Wiz独立发现了这两个漏洞。OpenAI表示，作为其“修补地球”计划的一部分，它花了两个月时间协调PHP维护者、安全研究人员、Cloudflare和政府网络安全机构共同应对。

这一努力被打乱了：软件供应链安全公司Chainguard在约定时间六个多小时之前发布了已修补的PHP容器镜像。CEO Dan Lorenc在LinkedIn上承认这一决定是他做出的，并指出Chainguard使用一个前沿AI模型和一句简单的提示词“在PHP中寻找糟糕的漏洞”独立重新发现了该漏洞。

Lorenc为这一决定辩护，指出已有攻击报告，而且该漏洞很容易复现。PHP基金会则辩称，提前发布可能帮助攻击者，而其他供应商仍在准备补丁。

“这无视了许多方数周来为协调披露所做的工作，”基金会指出。

PHP基金会董事会成员、Composer的创建者兼共同维护者Nils Adermann表示，“没有确认的漏洞利用”，并补充说任何被识别的活动都只是人们在尝试利用漏洞。

“你在未与PHP团队进行任何沟通的情况下单方面做出的决定，既不负责任也不专业。”

“在披露和公开发布之前有明确的禁发期，随着信息不断传来，这一禁发期经过了反复讨论和评估，权衡了被利用的风险与在更新不完整的情况下发布补丁的保护作用，”Adermann在回应Lorenc的帖子时写道。“你在未与PHP团队进行任何沟通的情况下单方面做出的决定，既不负责任也不专业。这里正确的做法是道歉，而不是为你明显的不当行为辩护。”

新常态

然而，PHP的混乱局面凸显了一个更大的担忧：AI让发现安全缺陷变得更容易，速度快于负责修复它们的人所能应对的速度。正如Lorenc本人所说：“不幸的是，这是行业的新常态。”

就在OpenAI披露的前一天，Anthropic发布研究显示，Claude在25个开源项目中识别出493个安全问题，这些项目涵盖超过500万行代码。其中一个配置缺陷21年来一直未被发现，并且有可能使一项身份验证要求失效，让未经授权的客户端能够访问本应受限的服务器。

虽然Anthropic的发现并非都是可利用的漏洞，但它们凸显了一个日益严重的问题：AI可以大规模发现安全弱点，但评估这些弱点并开发可靠的修复方案仍然需要时间和专业知识。

Akrites首席技术官、开源安全基金会（OpenSSF）首席技术官兼首席安全架构师Christopher Robinson表示，PHP紧急事件也提醒人们，在严重漏洞确实出现时做好准备至关重要。

“将PHP2Shell这类事件的影响降到最低的最佳方式，就是为这些事情的发生做好准备和规划。”

“将PHP2Shell这类事件的影响降到最低的最佳方式，就是为这些事情的发生做好准备和规划，”Robinson告诉The New Stack。“建立漏洞管理流程，并了解当问题变得过于复杂时谁能提供协助，这是开源项目和商业实体都能做的最好的事情。”

当发现漏洞变得比修复漏洞更容易

对于Michelle Tilley来说，为PHP所组织的那种应急响应很难在较小的开源项目中复制。她是Atuin的软件工程师兼CTO，Atuin是一个在GitHub上拥有超过32,000颗星的开源开发者工具。

“这里的响应看起来像是一场供应商紧急事件，有联盟、政府机构和WAF（Web应用防火墙）规则参与，”Tilley告诉The New Stack。“这对PHP这样的项目有效，但没有人会为一个默默无闻、只有3名维护者的库组建联盟，而结果却发现它被世界各地的软件所使用。”

“这对PHP这样的项目有效，但没有人会为一个默默无闻、只有3名维护者的库组建联盟，而结果却发现它被世界各地的软件所使用。”

Tilley说，Atuin本身已经收到越来越多AI生成的漏洞报告和拉取请求。虽然她的公司有足够的工程资源来处理这些，但许多较小的项目依赖无偿维护者在业余时间工作，他们可能会不堪重负而离开。

“这些开发者可能、也确实会精疲力竭，”Tilley继续说道。“有时他们会安排其他人接手项目；但很多时候，他们只是停止了对项目的工作，而下游使用者永远不知道。项目就是这样最终留下永远无法修补的漏洞。”

最终，她希望更多的责任落到研究人员和依赖这些代码的企业身上。

“没有单一的解决办法，但方向是明确的，”Tilley说。“修复的成本必须转移到发现漏洞的人和依赖这些代码的公司身上。”

这种压力也延伸到了更大的项目。AWS首席工程师、Valkey数据库维护者Madelyn Olson表示，Valkey今年发现并修复的安全漏洞也远多于以往。

“最难的部分已经从发现漏洞转变为修复漏洞，”Olson告诉The New Stack。“PHP就是一个很好的例子。”

一名PHP开发者最初是在修复2024年安全审计中发现的一个问题时，发现了本周其中一个漏洞背后的根本问题，该审计由开源技术改进基金（OSTIF）组织。然而，解决该问题的尝试陷入停滞，因为拟议的修复方案可能破坏兼容性、影响性能或干扰第三方扩展。据PHP基金会称，很少有工程师具备解决这些权衡所需的专业知识。

“AI在发现漏洞方面正变得非常擅长，”Olson说。“做出正确的修复仍然需要经验丰富的维护者，而这正是企业支持最重要的地方。”

“AI在发现漏洞方面正变得非常擅长。做出正确的修复仍然需要经验丰富的维护者，而这正是企业支持最重要的地方。”

为了应对大量涌入的报告，Valkey正在收窄其对安全漏洞的定义，使用AI检查自己的代码，并让向后移植和发布变得更易于产出。

Chainguard的争议也引发了披露时间表是否需要改变的问题。Olson回忆说，有三名研究人员在一周内各自使用LLM独立报告了同一个Valkey漏洞。Valkey现在正努力缩短禁发期——尽管这与打破已商定的发布日期是另一回事。

“如果你用LLM发现了一个漏洞，那么可以肯定地说别人也能发现它，”Olson说。“这支持缩短禁发期和加快发布，Valkey现在正努力缩短禁发期，这也是我们在大多数大型项目中看到的趋势。”

不断增长的安全积压

OSTIF执行董事Derek Zimmer表示，合法发现和低质量报告的数量都在造成积压，维护者不得不把稀缺的工程时间花在确认哪些问题是真的上。

“维护者正淹没在来自公众的漏洞报告海洋中，其中既有垃圾报告，也有合法报告，如果不花费大量时间进行分诊，几乎不可能将它们区分开来。”

“2026年的现实是，发现严重漏洞比以往任何时候都更容易，而维护者正淹没在来自公众的漏洞报告海洋中，其中既有垃圾报告，也有合法报告，如果不花费大量时间进行分诊，几乎不可能将它们区分开来，”Zimmer告诉The New Stack。

为了提供帮助，OSTIF正在试行Project V-LAT等举措，将工程师嵌入项目中以审查发现并开发修复方案，同时帮助维护者改进报告的处理方式。

Robinson还强调需要共享的安全专业知识和能够支持上游项目的专职工程师。他反驳了暴露更多缺陷必然使开源更不安全的说法，并指出依赖这些代码的公司有机会贡献修复方案。然而，许多项目既没有资金也没有专业知识来独立应对。

“大多数上游维护者在项目中也充当志愿者，几乎没有预算、基础设施或支持工具，”Robinson说。“这里不会有‘一刀切’的方法，我们需要使用多种并行方法来应对这种情况，以获得最广泛的成功机会。”

文章《PHP的安全紧急应对只是预演：AI挖掘漏洞的速度快于维护者修复的速度》首发于The New Stack。