一个开发者的GitHub账号被攻破，攻击者借它把恶意文件塞进了公司官方命令行工具的发布页。下载OVHcloud CLI的用户，本来只是做一次例行更新，却可能把本机保存的密钥交了出去。
这起供应链攻击发生在2026年10月19日。据OVHcloud首席执行官奥克塔夫·克拉巴（Octave Klaba）的说法，被篡改的文件在14:47出现，16:21被检测并拦截。从出现到封堵，中间隔了94分钟。
最先发现异常的不是公司自己，而是一名客户。这名客户注意到发布文件出现了可疑变动，随即向云服务商报告。克拉巴点名的受影响版本是v0.11.0、v0.12.0、v0.13.0、v0.14.0、v0.15.0，并确认v0.10.0是干净的。随后发布的v0.16.0被标记为不可变，意味着已发布的文件无法再被替换。
攻击者用的是一把现成的钥匙——一个已有的开发者账号，通过它往GitHub分发的软件里加入了一个恶意二进制文件。威胁因此被放进了用户信任的下载位置，一次普通的CLI下载，看起来没有任何理由让人起疑。至于这个开发者账号最初是怎么失守的，OVHcloud没有作出解释。
客户的报告指向的是发布文件被换成了后续提交的“脏构建”（dirty build）。在软件构建语境里，这个说法通常意味着改动超出了记录的源码版本。公开的问题列表把这份报告编为第300号，覆盖v0.13.0到v0.15.0被替换的资产；而OVHcloud的警告又额外点名了两个受影响版本。
这名客户还追问了改动背后的账号是谁，以及发布文件是否应当锁定、禁止替换。他说自己已经改用Go模块代理来构建，同时等待官方澄清。这份报告之所以公开，是因为该仓库没有私密的漏洞报告通道。
克拉巴把被加入的程序描述为一个二进制文件，任务是从磁盘上取回密钥。他评价这个程序质量很差，但同时警告它仍可能达成目的。目前披露的信息没有说明它搜索了哪些文件、收集到的数据被送往何处，也没有说明有多少用户执行了这些恶意下载。
CLI本身的日常角色，让这件事格外棘手。OVHcloud把这个工具定位为管理云服务、账户资源和自动化工作流的手段，其支持的身份验证方式包括一个本地.ovh.conf文件，里面存放凭据，此外还有用于应用密钥、应用秘密和消费者密钥的环境变量。
这些被写进文档的凭据位置，解释了为什么一个被攻破的管理工具，风险会超出下载的程序本身。但它们并不等于这份恶意软件的确认目标清单。在OVHcloud公布技术调查结果之前，任何关于SSH密钥、浏览器密码、持久化或攻击者基础设施的具体说法，都超出了现有证据。
这起事件符合一类更常见的模式：攻击者利用窃取到的发布权限，把熟悉的软件分发渠道变成凭据窃取的通道，用户甚至不需要访问一个假网站。OVHcloud敦促在事件期间下载过CLI的用户立即更新或删除它。克拉巴还建议受影响的用户更换磁盘上保存的所有密钥。
轮换之所以重要，是因为替换掉恶意程序，并不能作废那些可能已经被复制走的凭据。排查潜在暴露的组织，需要确认哪些机器下载并运行了受影响文件、保留可用证据、审查与可能暴露凭据相关的账户活动。如果那些机器上还有其他密钥，处置范围就不应只限于OVHcloud自己的凭据——公司的警告覆盖的是本机密钥的广泛范围，而不只是自家服务的密钥。
另一场相关的GhostAction GitHub凭据窃取行动，说明了仓库访问权限为何值得紧盯：那场行动用被盗账号，以可信身份引入恶意工作流。目前没有证据把它与OVHcloud事件联系起来。对OVHcloud用户来说，当务之急仍是替换受影响的下载、更新可能暴露的密钥，同时等待公司继续调查并公布更多技术细节。
热门跟贴