全球超过200万个项目依赖的PHP Composer,刚刚发布了两个"命令注入"高危补丁。攻击者能借漏洞在你的机器上执行任意代码——而你可能连一行恶意代码都没主动安装过。
漏洞藏在哪?一个你大概率没听过的驱动里
![]()
问题出在Perforce版本控制系统(VCS)驱动。Composer用它来拉取代码,但代码在拼接shell命令时没做充分转义。
Nils Adermann在官方安全公告里说得直白:「构造shell命令时,数值转义不充分。」
翻译成人话:Composer把外部输入的数据直接塞进系统命令,中间没加安全过滤。攻击者只要构造特殊的包元数据,就能让服务器执行他们想要的任何指令。
这不是Composer第一次踩这个坑。2021年它修复过类似的CVE-2021-29472,当时影响的是Mercurial和Git驱动。历史在Perforce身上重演了。
攻击路径:你甚至不需要主动安装恶意包
最麻烦的是利用门槛。根据安全公告,风险场景包括:
• 处理不受信任的项目(比如临时clone一个来学习的仓库)
• 解析恶意的包元数据(甚至不需要执行安装)
• 依赖某个被劫持的间接依赖
Composer会解析composer.json里的源信息来显示版本细节。这个解析过程就触发了漏洞——你还没敲下install,攻击就已经完成了。
Perforce在企业级PHP开发中用得不算最广,但金融、游戏、嵌入式领域的老项目里很常见。更危险的是供应链视角:你信任的包可能依赖了一个被篡改的Perforce源,而你完全不知情。
官方应急响应:比补丁更早的是"物理断网"
开发团队在4月10日做了一件事:直接在Packagist.org和Private Packagist上禁用了所有Perforce源的元数据发布。
这是"先止血再手术"的典型操作。哪怕你还没升级,新上传的恶意包也已经进不了主仓库。
他们还对两个平台做了全面扫描:Packagist.org的公共库,以及Private Packagist的企业私有环境。结果干净——目前没有发现利用这两个漏洞的现存包。
但"没发现"不等于"没有"。安全公告的原话是「目前没有野外主动利用的证据」,这是标准的免责声明句式。
你该做什么?两条路,没有中间选项
第一选择:立刻升级。运行composer.phar self-update到2.9.6,或者LTS版本的2.2.27。这是唯一被官方称为「绝对最有效」的方案。
第二选择:如果你暂时不能升级,只能祈祷。安全专家给的临时缓解措施只有一条:等Private Packagist的验证工具更新,用它扫描自有基础设施的恶意元数据。
没有配置开关能关闭Perforce驱动。没有环境变量能禁用相关功能。Composer的设计哲学是"约定优于配置",这次在安全场景里成了双刃剑。
检查你的版本很简单:composer --version。低于2.9.6的现行版,或低于2.2.27的LTS版,都在风险区。
为什么这件事值得PHP之外的人关注
Composer的漏洞模式正在变成通用风险模板。Node的npm、Python的pip、Rust的cargo——所有从远程源拉取代码并本地执行的包管理器,都面临同样的攻击面:
• 元数据解析发生在安装之前
• 版本控制驱动的shell命令拼接
• 供应链上游的间接污染
2024年XZ Utils后门事件已经证明,攻击者愿意花两年时间潜伏在压缩库这种"基础设施中的基础设施"。Composer的200万项目覆盖量,对同类攻击者来说是个足够诱人的目标。
这次响应速度值得肯定:从漏洞确认到全局禁用Perforce发布,再到补丁上线,节奏紧凑。但"全局禁用"本身也说明问题——当安全机制只能靠运营层面的"拔网线"来兜底,架构层面的设计债已经积累到一定程度了。
2.9.6和2.2.27的下载量数据还没公布,但可以确定的是:Composer的安装基数里,有大量跑在CI/CD管道和开发者笔记本上的实例,它们不会自动更新。这些沉默的大多数,才是真实的攻击窗口。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.