OVHcloud CLI 遭供应链攻击，0.11.0 至 0.15.0 版本二进制文件被替换

法国云与托管服务商 OVHcloud 的官方命令行工具 CLI 于 2026 年 10 月 19 日遭到入侵。据公司创始人 Octave Klaba 说明，黑客使用一名开发者的 GitHub 账号，替换了 0.11.0 至 0.15.0 版本在 GitHub 发布页面上的部分二进制文件，被替换的文件会在磁盘上搜寻机密信息。

OVHcloud 称受影响版本已在 94 分钟内全部删除，并于当日 17:16 UTC 发布干净的 0.16.0 版本。公司要求在该时间窗口内下载过 CLI 的用户尽快更换磁盘上的所有机密信息，包括 OVHcloud API 凭据、SSH 密钥与各类令牌。

事件经过

警报来自一次自动校验失败。一名客户在持续集成流程中固定了 Linux arm64 压缩包的 SHA-256 指纹，校验突然无法通过；他随后翻看发布列表，并在仓库中提交了第 300 号 issue。据这名报告者还原，v0.13.0、v0.14.0 和 v0.15.0 的压缩包在当天 12:47 至 13:12 UTC（巴黎时间 14:47 至 15:12）被替换，距原始发布已过去数周，上传者也不是当初上传这些发布文件的人。

OVHcloud 是总部位于法国鲁贝的云与托管服务商，提供独立服务器、虚拟机、网站空间和域名。其 CLI 让用户通过命令而非控制面板管理服务，是自动化运维人员的常用工具，运行需要 API 凭据授权。项目代码以 Apache-2.0 许可证开源，截至 2026 年 10 月 20 日仓库有 209 个星标，README 说明用户主目录下存在配置文件 .ovh.conf。

受影响版本与时间窗口

OVHcloud 给出的受影响版本为 v0.11.0 至 v0.15.0 共五个。不过公开记录了替换过程的只有 0.13.0 至 0.15.0 三个版本，0.11.0 和 0.12.0 目前只有公司方面的说法。仓库提供了一条间接佐证：10 月 20 日查询这些发布，五个版本都只列出四个文件，即 i386、Windows i386、Windows arm64 和 WebAssembly，64 位 Linux、macOS 以及 Windows x86_64 的压缩包均已不见。

具体到 v0.15.0，被替换的是 Linux arm64、Linux x86_64、macOS（Darwin）arm64 和 x86_64、Windows x86_64 的压缩包，以及本应用来核对下载内容的校验和文件；i386、Windows arm64 和 WebAssembly 的包未被动过。v0.14.0 和 v0.13.0 则只有 Linux arm64 压缩包和校验和文件有记录，其余文件报告者未作检查。v0.15.0 的 Linux arm64 压缩包指纹从 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0 变为 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb。

创始人 Octave Klaba 给出的暴露窗口为巴黎时间 14:47 至 16:21，共 94 分钟。他同时表示 0.10.0 和即将发布的 0.16.0 是干净的，初步检查未发现其他仓库受影响。消息次日在英语社交媒体上传开，International Cyber Digest 是 10 月 20 日转发的账号之一。

被替换文件的技术线索

新二进制文件自带一条明显线索。用 go version -m 读取元数据，该文件由 10 月 13 日的一次提交（标识为 5ead8ef9b43d）编译而成，带有未保存到 git 的改动，即 dirty 标记，也缺少发布流水线通常会写入的版本参数。换言之，它是手工编译的，并非出自 OVHcloud 的自动化流程。v0.15.0 标签仍指向提交 760fd72d，Go 模块代理提供的正是这个提交。

Klaba 称，黑客使用一名开发者的 GitHub 账号，添加了一个以读取磁盘机密信息为任务的二进制文件。他认为该文件质量平庸，但补充说它依然能把事情做完。按他的说法，技术原因是一项设置一直没有打开：GitHub 上的发布并非不可变，拥有相应权限的用户可以直接在平台上修改现有发布，这一步从未进入持续集成流水线，自动检查也就没有触发。该选项现已启用。

启用不可变发布后，Git 标签始终绑定在确定的提交上，附带的二进制和压缩包既不能修改也不能删除，要纠正错误只能发布新版本。攻击者持有开发者密钥仍可发布内容，却无法再改写已经流通的发布版本历史。访问权限问题仍悬而未决：OVHcloud 只提到一名开发者的账号，未说明是哪个账号、如何被拿下。报告者在 issue 中追问是凭据被盗、令牌泄露还是内部重建出了岔子，以及同一权限能否写入仓库代码，公司承诺随后几天给出详细分析。

官方回应与处置

OVHcloud 当天作出回应。团队成员在 issue 中写道，所有受影响的二进制文件已于巴黎时间 16:21 删除；Klaba 则在 X 上说明经过，并向报告问题的客户致谢。干净的 v0.16.0 于 17:16 UTC（巴黎时间 19:16）发布，成为目前的基准版本。项目负责人在 issue 中表示，该标签由其本人账号签名，发布本身不可变，因此附带的文件可信；GitHub API 的 immutable 字段也印证了这一状态，0.16.0 为 true，此前五个版本为 false。

公司还表示正在继续分析该二进制文件，将很快发布更多细节。报告者另指出，仓库当时没有启用漏洞私下报告功能，这正是警报最终落在公开 issue 里的原因。

用户自查与补救

风险集中在 10 月 19 日从 GitHub 下载过该 CLI 的人。官方指南给出三种安装方式：用 curl 运行脚本、Homebrew，以及从发布页面手动下载。install.sh 脚本从最新发布或标签指定版本下载压缩包，从文件内容看没有任何校验和或 SHA-256 检查，在该窗口运行过它的人拿到的就是页面上当时放置的文件。Homebrew cask 在发布时为每个压缩包固定 SHA-256，理论上事后被替换的压缩包会导致安装失败，但这属于推断。README 提到的 go install 从源码安装走 Go 模块代理，据 issue 所述代理提供的仍是该标签的原始提交。

自查方法是：装了 Go 的用户可运行 go version -m 查看已安装程序，若出现 +dirty 或 vcs.modified=true，且修订号为 5ead8ef9b43d，即为被替换的二进制文件。未出现这些信息并不足以断定干净，因为该检查只覆盖 issue 中描述的情形；由于该构建不带版本参数，ovhcloud version 命令可能不会显示 0.15.0，不宜只依赖它。另一种办法是核对 Linux arm64 压缩包指纹与上述两个值。

补救顺序上，先吊销再清理：在客户中心吊销并重新生成 OVHcloud API 凭据（.ovh.conf 文件及用 ovhcloud login 创建的凭据），随后处理 SSH 密钥、GitHub 和各云服务商的令牌、各项目的 .env 文件以及明文保存的密码。仅删除程序不够，因为会读取文件夹和环境变量的文件可能早已把内容送出。未在窗口内下载过的用户直接升级到 0.16.0 即可；自动化安装最好固定版本并校验 SHA-256。

报道同时列出若干局限：二进制文件的具体行为只有 OVHcloud 一家说法，无人公开分析；0.11.0 和 0.12.0 缺少独立证据；OpenSourceMalware 的分析将该账号与三月的一次入侵及 GlassWorm 组织联系起来，但依据只是账号身份，OVHcloud 未确认这一归因；公司未公布下载日志，94 分钟内被下载的文件数量与暴露人群规模无从估算。

要点

替换窗口为巴黎时间 14:47 至 16:21，共 94 分钟
被替换二进制由 10 月 13 日一次提交编译，带 dirty 标记
0.16.0 于 10 月 19 日 17:16 UTC 发布，标签已签名
GitHub 发布不可变选项在事件后才启用