Why the OVHcloud CLI Attack Beat Every Verification Step You Trust
The build server failed a routine check on a Monday afternoon. That failure was the only alarm that rang. Someone had quietly reached back into five old OVHcloud CLI releases and swapped the download files for malware.
What Happened?
On October 19, between 12:47 and 13:12 UTC, a hijacked contributor account replaced the release archives on five versions of the OVHcloud command line tool, v0.11.0 through v0.15.0. Those versions had been published between April and September.
On each one, the attacker swapped the macOS, Linux, and Windows x86_64 archives and the checksums file, leaving the i386, Windows arm64, and WebAssembly builds alone.
I compiled the replacement binary by hand on a messy working tree, not through the official release pipeline. A customer who pins file fingerprints in CI saw the mismatch, pulled the metadata, and filed a public issue. The files came down at 14:21 UTC, 94 minutes after they went live.
Why It Worked
Here is the part that stings. The attacker also rewrote checksums.txt, the file whose entire job is to prove a download is honest. Compare the archive against the published list, and both sides agree, because the same person handwrote both.
Release immutability was switched off, so anyone holding write access could edit a release that shipped six months earlier. The version tag never moved. The commit never moved. Only the file you actually run changed.
What’s the Impact?
Anyone who used the install script, downloaded straight from a release page, or ran the built-in upgrade command during that window may have handed over every secret sitting on that disk. Homebrew installs, source builds, and the Docker image were untouched. The clean build is v0.16.0, now published with immutability on and an attestation attached.
How to Avoid This
- Pin fingerprints, verify on every build
- Turn on release immutability
- Demand signed releases and attestations
- Alert on force pushes and odd maintainer activity
- Rotate secrets from a different machine
Indicators of Compromise
OVHcloud CLI release swap, October 19, 2026
Published indicators only. No copy of a swapped archive was preserved before deletion, so hashes exist for one file and behavioral checks carry the rest.
Affected releases
Timeline, UTC
File hashes, SHA-256
Build metadata on the fake binary, go version -m
Loader artifacts tied to the same account earlier in 2026
Hunt and verify
Scope of exposure: install script, direct release downloads, unpinned CI fetches and the in product upgrade path. Homebrew, go install, source builds and the Docker image were not affected. Rotate every secret readable from an affected machine, and rotate from a different machine.
Your Pipeline Trusted a File That Changed Last Tuesday
Supply chain attacks like this don’t trigger alerts. They pass every check you run, because the attacker edited the check.
Secure.com runs governed AI Teammates above the stack you already own, with your team setting the rules:
- Red Teammate attacks your own delivery path and shows which trust gap is actually reachable
- AppSec Teammate watches dependencies, pipelines, and release artifacts for drift from what you approved
- SOC Teammate assembles the case when a fingerprint breaks, instead of leaving it in a build log overnight
- Cloud Teammate traces which hosts ran the bad build and what those hosts could reach
- GRC Teammate keeps the evidence trail so you can prove to an auditor what moved and who approved it
Attack. Harden. Prove. Repeat. Your team sets the rules. AI Teammates do the work.
