DEV Community

Clydara profile image Clydara
Clydara for Clydara

Posted on

The OVHcloud CLI release swap: why the checksum file didn't help

#security #github #devops #supplychain

On Monday, October 19, 2026, someone used a hijacked contributor account to replace the download files on five old releases of OVHcloud's command-line tool on GitHub. The source code, the tags and the build pipeline were never touched. The swapped files were live for up to 94 minutes. What makes the incident worth studying is how it was caught, and why the usual "check the checksum" advice would not have caught it.

What happened (facts)

  • The swap. Between 12:47 and 14:21 UTC, archives on releases v0.11.0 through v0.15.0 were replaced: macOS x86_64 and arm64, Linux x86_64 and arm64, and Windows x86_64. Those releases were originally published between April 14 and September 16. The Linux i386, Windows i386, Windows arm64 and WebAssembly builds were left alone.
  • The checksum file went too. On v0.15.0 the attacker also replaced checksums.txt, so the published hashes matched the new binaries.
  • What the files were. OVHcloud says the new builds were designed to steal secrets stored on the disk of any machine that runs them. The bad binary was a plain local go build of a later commit (October 13), not something the release pipeline produced.
  • How it was caught. A customer's CI job pins the SHA-256 of ovhcloud-cli_Linux_arm64.tar.gz in its own configuration. The hash changed, the job failed, and the customer opened issue #300 at 13:50 UTC. OVHcloud deleted the swapped files about half an hour later.
  • The fix. OVHcloud published v0.16.0 that evening as an immutable release with a signed tag. A detailed postmortem has been promised.

Who was exposed

You could have received a swapped file during the window if you:

  • ran the official install.sh piped into sh (the script never checked a hash),
  • downloaded an archive from one of the five release pages,
  • ran a CI step that fetched the archive by URL without a pinned hash,
  • ran the CLI's own upgrade command from v0.12.0 to v0.14.0 on a script or manual install.

According to The Hacker News, you were not exposed through Homebrew (the cask pinned the original SHA-256), go install, a source build, or the Docker image, which had not been rebuilt.

What the coverage mostly skips

1. A checksum file next to the binary is not a security check. checksums.txt lives in the same release, under the same write permission, as the archive it describes. Anyone who can replace the archive can replace the hash. It protects you against a corrupted download, not a tampered one. The two installs that held up, Homebrew and the customer's CI, both kept the expected hash somewhere else.

2. Turning on immutability does not fix old releases. GitHub's docs on preventing release changes say plainly that immutability "will only apply to future releases". This attack hit releases from April to September. Enabling the setting today protects your next release, not the archive people may still be pinning from last spring.

3. The report had to be public. The customer filed a public issue because, per The Hacker News, the repository had no private reporting channel. Here it helped speed, but a public issue can also tip off an attacker before the files are gone.

What is not known yet

OVHcloud has not said which files the binary reads, where it sends them, how many copies were downloaded, or how the contributor's credentials were taken. OpenSourceMalware links the account to the GlassWorm campaign and calls that link its own inference. Treat the attribution as unconfirmed.

What to do

If you installed or updated the OVHcloud CLI during the window by one of the exposed paths, treat every secret readable from that machine as exposed. Rotate them from a different machine, then install v0.16.0.

For anything you ship or download from GitHub releases, the practical takeaway is to keep the hash outside the release:

# CI: pin the expected hash in your own repo, not in the release
TOOL_URL="https://github.com/OWNER/REPO/releases/download/vX.Y.Z/tool_Linux_arm64.tar.gz"
TOOL_SHA256="<hash you recorded when you first reviewed this version>"
curl -fsSL -o tool.tar.gz "$TOOL_URL"
echo "${TOOL_SHA256}  tool.tar.gz" | sha256sum -c -   # fails the job if the file changed

# For an immutable release, also check GitHub's release attestation
gh release verify-asset vX.Y.Z ./tool.tar.gz --repo OWNER/REPO
Enter fullscreen mode Exit fullscreen mode

The point is where TOOL_SHA256 lives: in your repository, reviewed once, not fetched from the same release page as the archive. That is exactly the check that failed loudly for the customer who caught this swap.

If you maintain a project that publishes binaries: enable immutable releases, publish from a draft so assets are attached before the release locks, and turn on private vulnerability reporting so the next person who notices something can tell you quietly.

Sources

Written with AI assistance and checked against the sources above.

Top comments (0)