PHP补丁提前6小时泄露，基金会指Chainguard破禁

周三，一些网站短暂下线了。运营方把服务停掉，等两个PHP关键漏洞的修复程序。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；使用更早分支的用户需要升级到受支持版本，或使用发行方的向后移植（backport）。

这场被称作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补充说：“这就是互联网级漏洞的样子。当一个缺陷击中如此普遍的技术时，爆炸半径不是一个产品、一个行业，而是整个网络。”

在这些警告背后，开源领域的负责人正在争论：当发现速度快过修复速度时，行业该如何应对。PHP的案例还多了一层争议——当细节开始泄露后，禁令是否还在保护用户。

披露争议与一次失败承认

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

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日周一开始泄露，10月20日周二晚讨论加剧，当时多家厂商报告了他们认为是野外的利用。

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

Lorenc说，三个考虑驱动了这个决定：Chainguard独立发现漏洞并构建利用有多容易；关于漏洞和修复的信息已经流传了多少；以及共享的关于活跃利用的证据。

Chainguard把打补丁的镜像公开，而不是只对客户开放。Lorenc承认PHP基金会不同意他的决定。

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

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

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

什么才算利用

分歧集中在什么算作活跃利用的证据。Lorenc说其它厂商看到了野外利用。PHP基金会说，其安全团队在发布时并未在流传的概念验证中识别出可用的利用。

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

相互竞争的风险很清楚。维持禁令能让发行方有时间一起准备更新。提前发布修复可能保护能拿到它的用户，但在其它PHP用户还在等补丁时，也给攻击者留下了线索。

底下那个大写的B问题

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

基金会称，相互竞争的修复方案在兼容性和安全性上存在艰难的取舍，工作反复停滞。它把这一延迟称为“结构性失败”，原因是其决策流程和资源不足。

基金会现在正向依赖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漏洞说明了组织可能很少想到的可靠软件中的风险。他说，稳定的生产软件容易被忽视，即使AI驱动的发现提高了漏洞发现的数量和速度。他强调要从可信供应商获取经过测试的更新。“鉴于这些漏洞的潜在影响，红帽建议客户从包括红帽在内的可信来源获得经过验证、测试的补丁后尽快部署，即使不在正常补丁窗口内。”

HackerOne首席执行官Kara Sprague在发给媒体的声明中说：“PHP的发现也提醒我们，开源安全是每个人的责任。支撑数百万网站的软件，不能依赖少数维护者独自应对日益复杂的威胁。”

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

这也是各种评估的交汇点。资金更充足的维护者、更有韧性的披露流程、更广泛的防御工具获取渠道，可以解决长期问题。那才是本周补丁底下那个大写的B问题。