PHP漏洞引爆骂战：有人提前6小时抢跑，基金会怒斥不专业

一场围绕PHP的安全风波，正在演变成开源圈罕见的公开互撕。被称为PHP2Shell的两个高危漏洞，能让未认证攻击者在受影响服务器上执行恶意代码。企业、医院、学校、政府机构一度临时关停网站和在线服务，Cloudflare紧急部署防火墙规则，Automattic确认WordPress.com、WordPress VIP和Tumblr已完成防护，维基媒体基金会则把多项辅助服务下线，直到补丁就位。

PHP项目在周三为8.2到8.5版本发布了紧急修复。更老的版本已不在官方支持范围内，部分发行版和厂商提供遗留修复，PHP也为7.4到8.1版本发布了有限的补丁。

但真正让社区炸锅的，是漏洞被发现、修复和披露过程中的一段插曲。

提前六小时的“抢跑”

补丁消息在周二提前泄露，原定披露节奏被打乱。随后OpenAI披露，安全公司Calif用其GPT-5.6 Sol模型发现了其中一个漏洞，谷歌旗下的Wiz则独立识别出了两个漏洞。OpenAI称，它花了两个月协调PHP维护者、安全研究者、Cloudflare和政府网络安全机构共同应对，这属于其Patch the Planet计划的一部分。

协调在软件供应链安全公司Chainguard提前发布已修复的PHP容器镜像后被打断——比约定时间早了六个多小时。CEO Dan Lorenc在领英上承认这一决定由他做出，并称Chainguard用前沿AI模型和一句简单的提示词“find bad vulnerabilities in PHP”独立复现了该漏洞。

Lorenc为自己的决定辩护，理由是已有攻击报告，且漏洞复现门槛很低。PHP基金会则认为，提前发布可能在其他厂商还在准备补丁时帮到攻击者。

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

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

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

Adermann在回应Lorenc的帖子时写道：“在披露和公开发布之前有明确的禁发期，随着信息不断到来，这一安排被反复讨论和评估，权衡的是被利用的风险与在更新不完整时发布补丁的保护作用。”“你单方面做出的决定既不负责任也不专业。正确的做法是道歉，而不是为自己的明显不当行为辩护。”

“这不幸是行业的新常态”

这场混乱指向一个更大的问题：AI让发现安全漏洞变得更容易，速度快过负责修复的人能响应的速度。正如Lorenc自己所说：“这不幸是行业的新常态。”

就在OpenAI披露的前一天，Anthropic发布研究称，Claude在25个开源项目、超过500万行代码中识别出493个安全问题。其中一个配置缺陷潜伏了21年，可能关闭一项认证要求，让未授权客户端访问本应受限的服务器。

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

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

“把PHP2Shell这类事件的影响降到最低的最好方式，就是为这些事情的发生做好准备和规划。”Robinson说，“拥有漏洞管理流程，并了解当问题过于复杂时谁能提供帮助，是开源项目和商业实体能做的最好的事。”

发现比修复容易之后

对Atuin的软件工程师兼首席技术官Michelle Tilley来说，PHP这种级别的应急响应，较小的开源项目很难复制。Atuin是一个开源开发者工具，GitHub星标超过32000。

“这里的响应看起来像一场厂商紧急行动，有联盟、政府机构和WAF（Web应用防火墙）规则。”Tilley说，“这对PHP这样的项目行得通，但没人会为一个默默无闻、只有3名维护者、却出现在世界各地软件里的库组建联盟。”

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

“这些开发者会、也确实会 burnout（倦怠）。”Tilley说，“有时他们会安排别人接手项目；很多时候他们只是停止工作，下游使用者永远不知道。项目就是这样留下永远得不到修补的漏洞。”

她希望更多责任落到研究者和依赖这些代码的企业身上。“没有单一的解法，但方向是清楚的，”Tilley说，“修复成本必须向发现漏洞的人和依赖代码的公司转移。”

压力同样传导到大项目。AWS首席工程师、Valkey数据库维护者Madelyn Olson表示，Valkey今年发现并修复的安全漏洞远多于以往。

“最难的部分已经从发现漏洞转移到修复漏洞。”Olson说，“PHP就是个好例子。”

本周其中一个漏洞背后的底层问题，最早由一名PHP开发者在修复2024年一次安全审计中发现的问题时识别出来，那次审计由开源技术改进基金（OSTIF）组织。但解决尝试陷入停滞，因为拟议的修复可能破坏兼容性、影响性能或干扰第三方扩展。据PHP基金会称，很少有工程师具备处理这些取舍的专业能力。

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

为应对涌入的报告，Valkey正在收窄安全漏洞的定义，用AI检查自己的代码，并让向后移植和发布更容易。Olson回忆，一周内有三名研究者各自用大模型报告了同一个Valkey漏洞。Valkey正朝着更短的禁发期努力——尽管这与打破约定的发布日期是两回事。

“如果你用大模型发现了一个漏洞，可以安全地说别人也能发现它。”Olson说，“这支持更短的禁发期和更快的发布，Valkey正在朝更短的禁发期推进，这是我们在大多数大型项目中看到的趋势。”

越堆越高的安全积压

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

“2026年的现实是，发现严重漏洞比以往任何时候都容易，维护者淹没在公众提交的漏洞报告海洋里，其中既有垃圾报告也有真实报告，不花大量时间分诊几乎无法区分。”Zimmer说。

为此，OSTIF正在试点Project V-LAT等项目，把工程师嵌入项目，审查发现并开发修复，同时帮助维护者改进报告处理方式。

Robinson也强调共享安全专业知识和专职工程师支持上游项目的必要性。他不认同“暴露更多漏洞必然让开源更不安全”的说法，指出依赖这些代码的公司有机会贡献修复。但许多项目既没有钱也没有专业能力独立响应。

“大多数上游维护者在项目中也扮演志愿者角色，几乎没有预算、基础设施或支持工具。”Robinson说，“这里不会有‘一刀切’的方案，我们需要用多种并行方法来争取最广泛的成功机会。”