AI 发现 PHP 两个高危漏洞，Chainguard 提前发布补丁引发披露争议

你最喜欢的网站之一周三是不是打不开了？有些确实如此，因为运营者在等待修复两个严重漏洞期间将服务下线，而这两个漏洞出在支撑着互联网大部分内容的语言 PHP 中。

这一预防措施并不意味着那些网站遭到了黑客攻击。这些漏洞本身是极其糟糕的坏消息。但更值得关注的长期问题，或许是补丁禁令（embargo）的处理方式。

PHP 驱动着大约 70% 的网站，但这一数字描述的是 PHP 的覆盖范围，而非存在漏洞或已遭入侵的网站数量。

WordPress 已告知网站所有者更新 PHP；这些漏洞并不需要更新 WordPress。

这两个漏洞是 CVE-2026-109618 和 CVE-2026-109619。PHP 项目的修复版本为 8.2.35、8.3.36、8.4.27 和 8.5.12；使用较旧 PHP 分支的用户需要升级到受支持的版本，或使用发行版提供的向后移植补丁。

这场 PHP 安全紧急事件，又称 PHP2Shell，暴露出的不只是这种广泛使用的语言中的危险漏洞。此次发布还引发了一场关于协同披露的争议，并凸显了开源维护者所承受的压力——随着 AI 辅助的研究人员更快地发现并开发漏洞利用。

通往这场紧急事件的道路经过 OpenAI 的 Patch the Planet 计划。在该计划中开展工作的安全公司 Calif 使用 GPT-5.6 Sol 找到了一条实现远程代码执行的路径，并于 8 月 11 日向 PHP 报告。OpenAI 当天独立报告了同一底层问题；Wiz 于 8 月 24 日报告了其发现。PHP 的维护者主导了修复工作。他们早在 2024 年就发现了底层内存耗尽问题的迹象，但其完整影响直到今年 8 月才变得清晰。

“这几乎是一个严重漏洞所能达到的最广泛影响范围。”

OX Security 的 Moshe Siman Tov Bustan 在一份声明中表示：“这几乎是一个严重漏洞所能达到的最广泛影响范围。如果你有一个可公开访问的 PHP 实例且尚未打补丁，那就应当假设自己已暴露。如果你发现被利用的证据，就应假设已遭入侵，而不仅仅是暴露。”

OX Security 首席执行官 Neatsun Ziv 补充道：“这就是互联网级漏洞的样子。当一个漏洞波及如此无处不在的技术时，爆炸半径不是一个产品或一个行业，而是整个互联网。”

在这些警告背后，开源领导者们正在争论：当漏洞发现的速度超过修复速度时，业界应如何应对。The New Stack 曾报道过维护者面临大量 AI 生成的漏洞报告；PHP 的案例又增添了一场争议：一旦细节开始泄露，禁令是否仍在保护用户。

一场披露争议与一次失败承认

在补丁发布之前，PHP2Shell 的细节就开始泄露。PHP 基金会称，10 月 20 日有两个 CVE 编号开始流传，随后是一段意外发布的漏洞验证视频。

Chainguard 首席执行官兼联合创始人 Dan Lorenc 随后在 10 月 21 日协调发布前六个多小时发布了已打补丁的容器镜像。他表示，他认为有关在野活跃利用的报告足以证明打破禁令的决定是合理的。

对速度的担忧是真实存在的：在 WordPress 于 9 月 22 日发布 7.1.2 版以修复 CVE-2026-87902 之后，Patchstack 当天就观察到针对 WordPress 网站的探测，次日又出现了写入文件的尝试。

顺便说一句，这已经够糟了。但 WordPress 这一事件并不能确定，当 Chainguard 发布其镜像时，攻击者是否成功利用了这些 PHP 漏洞。

Lorenc 为何提前行动

在给 The New Stack 的一封电子邮件中（其内容后来也反映在他的 LinkedIn 帖子中），Lorenc 表示 Chainguard 用其测试工具和一个被提示“找出 PHP 中的严重漏洞”的前沿 AI 模型，独立发现了同一问题。

Lorenc 说，Chainguard 最早在 10 月 16 日周五听说将有一个 PHP 问题。它当晚独立发现了该问题，于 10 月 17 日周六收到完整简报，并协助测试了修复。

他说，消息在 10 月 19 日周一开始泄露，讨论在周二晚上加剧，当时多家厂商报告了他们认为是野外的漏洞利用。

Lorenc 写道，在与其它研究人员进行视频通话后，他决定发布修复，并立即通知了披露小组。他说，他认为协同披露准则允许在有在野利用证据时提前发布。

Lorenc 说，有三个考虑因素促成了这一决定。分别是：Chainguard 独立发现该漏洞并构建漏洞利用有多么容易；关于这些漏洞和修复已经有多少信息在流传；以及所分享的关于活跃利用的证据。

Chainguard 将其已打补丁的镜像公开，而不是仅限客户使用。Lorenc 承认 PHP 基金会不同意他的决定。

他们当然不同意。PHP 基金会的说法更为直白：“Chainguard 单方面打破了禁令，发布了包含修复的构建镜像。”它表示，Chainguard 提前收到补丁是为了让客户能在约定的披露时间进行更新。

在基金会看来，发布构建镜像让攻击者有机会研究修复，而其他 PHP 用户仍在等待补丁。

“我们不可能永远都做对，也不是每个人都会认同我们的决定。”

Lorenc 写道，他很抱歉自己的决定给 PHP 的维护者增加了压力。“我们不可能永远都做对，也不是每个人都会认同我们的决定，”他说，并补充道 Chainguard 的目标是保护尽可能多的人。

什么才算作漏洞利用？

分歧的核心在于什么才算作主动利用的证据。Lorenc 表示，其他厂商已经看到了在野利用。PHP 基金会则表示，其安全团队在发布时并未在流传的验证性利用代码中发现可用的漏洞利用。

亚马逊威胁情报后来报告称，10 月 17 日其一个蜜罐遭到了一次明显的漏洞利用尝试，10 月 21 日清晨又有更多尝试。不过，它表示尚不清楚这些尝试在真实系统上是否会成功。

相互竞争的风险显而易见。是的，维持禁令能让发行商有时间共同准备更新。而且，提前发布修复确实可能保护那些能够获取它的用户。但这也会在其他 PHP 用户仍在等待补丁时给攻击者提供线索。

底层的核心问题

PHP 基金会还承认了其应对中的另一项失误。开发者在 2024 年的一次审计中注意到某个 CVE 背后存在内存耗尽问题的迹象，但当时并未找到通往远程代码执行的具体路径。

基金会表示，相互竞争的修复方案在兼容性和安全性上存在艰难的权衡，相关工作一再停滞。它称这一延迟是其决策流程和资源不足造成的“结构性失败”。

The New Stack 此前曾报道过付费维护与安全实践之间的联系。该基金会目前正在向依赖 PHP 的公司、主机商和政府寻求更多支持。

Ubuntu Linux 的母公司 Canonical 对整体应对给出了不那么严厉的评价。Canonical 安全工程经理 Luci Stanescu 在一封电子邮件中表示：“Canonical 支持并建议按照最佳实践进行协调式漏洞披露。第三方提前泄露禁令令人遗憾，但我们认为披露流程运行良好。”

这一评价与 PHP 基金会的批评在侧重点上有所不同：泄露可能损害流程的一部分，但不一定会使更广泛的协调努力失效。

对于 CIQ 首席技术官 Peter Nelson 来说——其公司是 Rocky Linux 的创始赞助商——PHP 这一事件契合了 Linux 安全领域已经在发生的更广泛变化。

“过去六个月里，我们看到 AI 被用于利用内核空间中的漏洞，”Nelson 说。“这意味着更多研究正投入到 PHP 等其他广泛使用的软件程序中。我们预计，随着开源项目继续使用 AI 和其他手段来加固代码并更好地防御此类漏洞，这种情况会越来越多。”

“如今，此类漏洞利用需要前沿模型。明天就不会是这样了。”

Nelson 预计，随着先进的漏洞研究能力变得更加普及，这种压力将持续下去。“如今，此类漏洞利用需要前沿模型。明天就不会是这样了。”

Lorenc 还将这一挑战描述为整个行业的问题，而非仅限于 PHP。“不幸的是，这是行业的新常态，我们需要作为一个团队共同努力，才有机会足够快地保护我们的关键基础设施，阻止攻击者造成真正的伤害。”

打补丁不能等待常规维护窗口。

对于企业用户来说，直接后果是运营层面的。红帽公司副总裁兼 Lightwell 总经理 Gunnar Hellekson 在给 The New Stack 的电子邮件中表示，PHP 的这些漏洞凸显了企业可能很少考虑的可靠软件中的风险。Lightwell 是红帽与 IBM 为应对易受攻击的开源依赖而共同开展的项目。

Hellekson 表示，即使 AI 驱动的发现提高了漏洞发现的数量和速度，稳定的生产软件也很容易被忽视。他说，PHP 的问题提醒我们，开源已深深融入支撑企业运营的系统之中。

他强调要从可信供应商处获取经过测试的更新，尤其是当漏洞影响 PHP 等关键程序时。“鉴于这些漏洞的潜在影响，红帽建议客户在从红帽等可信来源获得经过验证、测试的补丁后尽快部署，即使不在常规补丁窗口内。”

“支撑数百万网站的软件不能只依赖少数维护者来独自应对日益复杂的威胁。”

除此之外，总体而言，我们需要为开源软件的维护和安全投入更多资源。正如 HackerOne 首席执行官 Kara Sprague 在发给媒体的声明中所说：“PHP 的这些发现也提醒我们，开源安全是每个人的责任。支撑数百万网站的软件不能只依赖少数维护者来独自应对日益复杂的威胁。”

不，确实不能。

对于运行受影响 PHP 系统的组织来说，“立即打补丁！”的问题依然存在：部署修复后的构建版本，并检查系统是否有尝试利用的迹象，包括可追溯到 10 月 17 日的活动。

这正是各种相互竞争评估的交汇点。资金更充足的维护者、更具韧性的披露流程以及对防御工具的更广泛获取，可以解决长期问题。而这正是本周补丁背后的核心问题。

文章《AI 发现了一个关键的 PHP 漏洞。更大的失败始于 2024 年。》首发于 The New Stack。