2026-10-24 10:01:24 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

云CLI版本号没变，里面的二进制已经被换过

原创

tcode
tcode

字节脉搏实验室

2026年10月21日 11:29
北京

去阅读

摘要：OVHcloud命令行工具五个旧版本的发布文件曾在一小时半内被人替换，恶意二进制会收集云凭据和开发工具数据。文章按下载时间、文件哈希和Go构建信息给出无执行判断，并说明为什么版本号不能证明文件完整。

10月19日，一个客户在CI里安装OVHcloud命令行工具时发现哈希对不上：脚本盯着的Linux arm64压缩包突然变成了另一个文件。异常没有藏在源码提交里，也没有等下一次正式发布才出现；攻击者用一个被入侵的OVHcloud开发者GitHub账号，直接替换了v0.11.0至v0.15.0已有的下载资产。OVHcloud随后发布的GitHub安全公告把恶意文件可下载窗口定为中欧时间14时47分至16时21分，即北京时间20时47分至22时21分，持续1小时33分钟。

这是一条容易被“版本没变”掩盖的供应链事件。正常发布里，版本号、标签、源码提交和产物之间有固定关系；这次被改的是标签下面挂着的压缩包和校验文件。OVHcloud的公告称，源码、标签和构建流水线没有被改，只有GitHub上的发布资产遭到替换。用户即便看到熟悉的v0.15.0，也可能下载到后来从另一个提交临时构建的二进制。版本号说明发布意图，文件哈希才说明眼前这个文件到底是不是那次构建。

事件的时间线也有一个具有操作意义的拐点。GitHub Issue #300显示，替换在10月19日约12时47分至13时12分UTC被发现和继续发生，客户当时只是注意到固定哈希失效；之后OVHcloud排查并把恶意资产清除，再发布新版本。这个先后关系说明检测信号并不神秘：不是安全人员先识别出病毒，而是供应链完整性检查先制造了一个失败。组织若把所有哈希失败都当作“上游又改包了”并手动跳过，就会把最该阻断的替换动作放行。

受影响平台并非全部。公告列出恶意版覆盖macOS x86\_64与arm64、Linux x86\_64与arm64、Windows x86\_64；The Hacker News进一步核对发布清单后指出，Linux i386、Windows i386、Windows arm64和WebAssembly资产没有被替换。更关键的是时间条件：只有在这93分钟内下载并安装、而且随后运行了受影响平台二进制的人，才需要把本机保存的凭据视为可能暴露。更早下载并保存未动过的文件、使用Homebrew且校验和匹配成功的安装、用go install或源码自行构建的路径，与直接抓取发布归档不同。

公告给出的下载统计约为250，但这个数字首先代表可疑资产被下载的次数，不直接等于250台电脑已经失陷，也不直接等于250组云账号被盗。判断还需要经过执行时间、平台和文件哈希三道门。恶意程序可能只被保存到缓存、被下载到CI临时目录，或者在运行前被哈希固定策略拦下；也可能在同一份下载包被多台机器复用。规模数字适合安排排查优先级，不能替代主机侧证据。

版本路径也需要逐项核实。通过包管理器安装、从源码构建、复用早先缓存的归档，以及从Release直接下载并执行，四种路径的暴露条件不同；下载到但从未执行，与运行后才开始读取本机文件也不同。公告称源码与构建链未被改动，不等于“从源码安装”始终可安全跳过后面的审计，因为构建依赖和缓存仍可能来自别处。最稳妥的办法是同时记录安装来源、下载URL、文件摘要、执行时间和构建机身份，让每个二进制都能回到一条可核验的链上。

OVHcloud公开了各平台的恶意二进制MD5。管理员应先复制一份可疑文件做离线核验，不要在未确认前再次运行。Linux可用md5sum，Windows PowerShell可用Get-FileHash -Algorithm MD5，macOS可用md5。哈希命中只证明文件属于这个已知恶意版本；没有命中也不等于永久安全，若当初的下载文件已被删除，就要从安装时间、CI下载日志、代理记录和发布窗口去还原。任何自动更新脚本都可能把下载动作藏进流水线日志，必须把构建机和个人开发机一起查。

如果文件还在，Go工具链提供了另一种只读线索。运行go version -m并指定二进制路径，它读取嵌入的模块与构建信息，不启动工具本身。已披露的恶意v0.15.0 Linux arm64样本显示模块伪版本为v0.15.1-0.20261013083505-5ead8ef9b43d+dirty，构建提交是5ead8ef，且记录里有-ldflags=\"-s -w\"；干净的v0.16.0显示正式版本号，提交关系也不同。The Hacker News提醒，不能用“带+dirty就是恶意”作为唯一规则，因为官方自己的干净构建也可能带这一标记。要把三项放在一起看，并与官方发布元数据核对。

文件哈希与构建信息解决的问题不同。哈希回答“这个字节串是不是已知归档”，适合快速锁定公告列出的事件样本；构建信息回答“这份二进制声称从哪个模块和提交来”，适合解释为何它看起来像正常版本。两者都对不上时，不能马上改做字符串搜索或在线沙箱上传，后者可能泄露文件里的额外内容。应先复制样本、记录哈希、保留原始下载路径与访问日志，再交给有隔离环境的团队分析。若文件已经被删除，代理日志中的目的域名和下载时间就是重要的第二现场。

真正的暴露面由本机文件决定。安全公告列出的收集目标包括VS Code、Cursor、Continue、Cody、OpenCode、Claude及Hermes的配置或会话数据，也包括AWS、Google Cloud、Azure、Docker、Kubernetes、SSH、netrc、Terraform、DigitalOcean和Git凭据。这说明恶意程序并未针对OVHcloud登录令牌设置单一目标。若受影响二进制已经运行，单改CLI密码可能不够；本机保存的云访问密钥、源码托管令牌、Kubernetes凭据、SSH私钥和部署系统凭据都要按权限范围处理。

处置顺序应以阻止继续外传为先。先隔离可能运行过可疑二进制的个人机与CI构建机，保留进程、网络连接、命令行、安装日志和文件样本；阻断公告列出的外传地址45.32.148.174:443及对应域名，但不要只依赖封锁一个地址。随后从云控制台和身份系统列出下载窗口内活跃的访问密钥、会话与令牌，先暂停或轮换高权限凭据，再处理普通账号。清除恶意文件后，应从v0.16.0的正式发布或可验证的源码重新安装，不能把旧目录里的自动更新残留继续沿用。

凭据轮换不能只换CLI自己的登录状态。若本机曾保存云平台访问密钥、CI令牌、SSH私钥或Kubernetes配置，应按“能访问什么”的权限逐项撤销，而不是把同一把高权限密钥换个名字继续用。构建机尤其需要检查环境变量、缓存目录和发布权限，因为开发者的失陷可能被自动任务带进生产。轮换完成后还要复核最近是否存在异常下载、部署、镜像推送或对象存储访问，确认凭据没有在被发现前被使用。

这件事对CI管理员的提醒尤其直接。客户之所以发现替换，不是人工点开文件后觉得不对，而是流水线固定了SHA-256，下载内容一变就失败。凡是构建任务从GitHub Release、对象存储或镜像注册表拉取工具，都应锁定版本和摘要，而不是只锁定“latest”或标签；下载后先校验，再放进可执行目录；CI令牌不要默认拥有修改发布、环境变量和生产部署的全部权限。固定哈希不会阻止上游账号被入侵，却能把“悄悄换包”变成一次可以看见的失败。

OVHcloud在事件后启用了发布不可变设置，并在当晚发布带签名标签的v0.16.0。GitHub页面显示这次发布被标为Immutable，资产在规定后不能直接修改。The Hacker News援引对GitHub配置与时间线的核验称，替换发生前发布流程并未运行，而GitHub此前已经提供发布不可变能力。这里能得到的编辑判断不是“启用了某个按钮就能持续保障”，而是“可变的发布资产把原本可控的源码与构建信任关系断开”。标签签名、摘要锁定和不可变发布各自解决不同问题，缺一项都留下替换空间。

归因仍要留出空白。OVHcloud确认开发者账号被入侵，但没有在公告中说明凭据如何泄露；OpenSourceMalware把同一账号与GlassWorm活动联系起来，并明确把更远的关联写成推断。已知事实足以提醒用户检查本机凭据，却不足以把这次替换归给某个已确认身份。媒体对受影响版本的整理出现了“三个”与“五个”的差异，OVHcloud最终公告把v0.11.0至v0.15.0列为受影响资产，写作时采用厂商后发更新并保留时间线差异。

对开发者来说，可转述的问题不是“我装的是不是0.15.0”，而是“这个文件从哪来、下载时有没有固定摘要、是谁在什么时间执行了它”。如果答案只能回到一个可变下载链接和一句最新版本，风险面仍然存在。版本号可以告诉团队功能预期，哈希与构建信息才回答文件身份。把这三件事分开记录，下一次上游发布被替换时，CI至少有机会在恶意代码进入生产之前替人报警。

来源

GitHub Security Advisory，ovhcloud-cli security incident - October 19th, 2026，GHSA-862f-55f5-vmvw，2026-10-20发布，https://github.com/ovh/ovhcloud-cli/security/advisories/GHSA-862f-55f5-vmvw

ovh/ovhcloud-cli Issue #300，Release assets of v0.13.0-v0.15.0 replaced on 2026-10-19 with a dirty build of a later commit，2026-10-19，https://github.com/ovh/ovhcloud-cli/issues/300

GitHub Release，ovhcloud-cli v0.16.0，2026-10-19 17:16 UTC（中欧夏令时19:16），https://github.com/ovh/ovhcloud-cli/releases/tag/v0.16.0