返回资讯中心
外部精选
云计算
#容器平台#Containers#Open Source#Security

Chainguard回应提前发布PHP补丁:决定由我们自己做出

来源标题:Chainguard defends its choice to break the PHP security embargo: “We own the decision.”

Chainguard 在 KubeCon 上为其提前发布 PHP 补丁镜像辩护,称决定由公司自主做出。该公司比 10 月 21 日的协同安全发布提前六个多小时发布镜像,PHP 维护者指责这让攻击者抢先一步。Chainguard CTO Matt Moore 称,有迹象显示攻击者已能利用或接近利用这两个漏洞(CVE-2026-109618 和 CVE-2026-109619)。

The New StackSteven J. Vaughan-Nichols2026/11/12 · 今天30 分钟阅读

以下正文由 AI 翻译自 The New Stack(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

本周在 KubeCon + CloudNativeCon North America 2026 上,Chainguard 联合创始人兼 CTO Matt Moore 为公司提前发布已修复的 PHP 镜像这一决定进行了辩护——此举发生在与其他合作方约定的禁运期结束之前。

当 Chainguard 在 10 月 21 日协调安全发布前六个多小时就推送了修复后的 PHP 容器镜像时,PHP 的维护者指责该公司给了攻击者抢先一步的机会。Chainguard 则辩称,攻击者早已占得先机。

Chainguard 创始人兼 CTO Matt Moore

在接受 The New Stack 采访时,Moore 表示:“我们做这个决定,责任在我们自己。没有人能强迫我们这么做——但我们也不是在真空中做出这个决定的。”他还在与 TNS 的讨论中描述了参与禁运的其他各方,以及安全厂商关于在 Chainguard 发布镜像之前已有针对这些漏洞的活动报告。

Chainguard 并不是说他们修复得更快所以先发布。据 Moore 所说,Chainguard 认为攻击者已经能够利用这些漏洞,或者至少已经接近弄清如何利用——又或者正在试图弄清楚。

这两个漏洞分别是 CVE-2026-109618(内存耗尽导致的破坏)和 CVE-2026-109619(过期的全局状态),合称 PHP2Shell,属于严重的内存管理和错误处理缺陷。在特定条件下,未经认证的攻击者可以在 PHP 服务器上执行代码。

这两个漏洞涉及 PHP 对内存耗尽情况的处理,以及它未能在请求之间清除对已释放内存的引用。在第一个漏洞中,在错误的时机触及内存上限可能会导致 PHP 在完成内部数据设置之前被中断。后续处理可能将未完成的数据误认为有效信息。在第二个漏洞中,一个错误可能让 PHP 保留对先前请求中已释放内存的引用。随后的请求便可访问该无效内存。在可利用条件下,这些故障可能让攻击者在服务器的 PHP 进程中执行代码。

研究人员针对第一个漏洞演示了通过 Apache/mod_php 以及应用层 PHP-FPM 路径实现远程代码执行,并针对第二个漏洞在真实世界的 Apache/mod_php 应用上进行了演示。

这些是 PHP 本身的问题,不是管理员简单更新一个 WordPress 插件就能修复的。这是一个根本性的、严重的安全漏洞。

这些漏洞有多严重?

PHP 的公告根据通用漏洞评分系统(CVSS)v4.0 将两个漏洞均评为 9.2 分,即严重级别。可利用性取决于 PHP 构建方式、服务器配置、扩展以及应用行为。公告并未认定每一个 PHP 安装实例都可被攻破。PHP 在 8.2.35、8.3.36、8.4.27 和 8.5.12 版本中发布了修复。潜在暴露面相当大:截至 11 月 11 日,W3Techs 报告称,在它能够识别服务器端编程语言的网站中,有 68.8% 由 PHP 驱动。

根据 PHP 基金会的说法,一名开发人员在调查 2024 年一次安全审计中的问题时发现了内存耗尽问题,但当时并未确立具体的攻击路径。拟议的修复方案存在兼容性破坏、新的拒绝服务问题或跨 PHP 扩展变更的风险。

8 月 11 日,Calif 研究人员 Ryan A. 报告了同一底层问题导致的远程代码执行。自该日起,修复此问题成为 PHP 基金会安全团队的最高优先事项。OpenAI 独立报告了相同的底层缺陷。Wiz 于 8 月 24 日提供了额外的攻击向量,OpenAI 于 9 月 18 日报告了更多内容。

PHP 安全补丁是如何崩盘的

作为回应,PHP 的维护者与研究人员和分发商协调修复工作。随后,有关发布流程的细节开始泄露。

10 月 20 日,CVE 编号公开流传,并附带了错误的发布时间和严重性评分。PHP 对此发出警告,并将发布时间提前一天,至 10 月 21 日 14:00 UTC。报告安全公司之一的 Calif 随后误发布了一段演示其概念验证的视频。尽管视频被删除,副本仍在流传。PHP 还承认,提供给关键基础设施供应商的缓解建议可能已经泄露。

简而言之,在 Chainguard 发布任何内容之前,信息环境已经一团糟。

但 PHP 基金会坚持认为,其剩余的协调窗口仍有意义:具体来说,分发商正在打包修复程序,立即发布将使许多用户没有直接的更新途径。10 月 21 日 07:41 UTC,Chainguard 还是发布了修复后的镜像——比约定时间早了 6 小时 19 分钟。

PHP 基金会批评了这一举动:“Chainguard 单方面破坏了禁运,发布了包含修复的构建镜像。”它认为,这意味着“任何攻击者现在都可以研究二进制形式的修复,而其他所有 PHP 用户仍在等待发布。”

一个修复后的二进制文件保护了安装它的人。它也可能告诉攻击者该往哪里看。

这就是 PHP 基金会的核心反对意见。修复后的二进制文件保护了安装它的人。它也可能告诉攻击者该往哪里看。

Moore 的辩护:优势早已转向攻击者一方

Moore 并不否认发布修复后的二进制文件可能帮助攻击者。他辩称,到那时,禁运本应保护的优势早已被侵蚀。

他告诉 The New Stack,当只有防御方知道漏洞时,保密性给了他们准备的时间。一旦攻击者掌握了足够的信息来利用漏洞,扣留可用的修复程序反而会逆转这一优势:攻击者可以行动,而禁运之外的用户无法保护自己。

“如果我们看到野外的利用活动,我们就有责任发布,”Moore 说。据他所述,正是其他安全厂商的报告推动 Chainguard 得出了这一结论。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →