The OVHcloud CLI Swap and How to Verify Downloads

Attackers swapped OVHcloud CLI release archives and their checksum file for 94 minutes. What caught it, and how 37 popular CLIs let you verify downloads.

On October 19, a CI job that installs the OVHcloud CLI started failing. Its own build hadn’t changed. The SHA-256 of the Linux arm64 archive it downloaded no longer matched the hash pinned in the job, so the job stopped. That failure was the first sign that the release files on GitHub had been replaced with a secret stealer.

Plenty of other installs that window didn’t fail. The official install script didn’t check a hash. Neither did anyone who downloaded the archive and compared it to the checksums.txt on the same release, because the attacker had replaced that file too. This write-up covers what happened, why the usual checks missed it, and what verification the tools you install in CI actually offer.

What happened

OVHcloud’s security advisory and reporting by The Hacker News and SecurityWeek give this timeline, in UTC:

The source code, tags, and build pipeline weren’t touched. The release workflow didn’t run at all. The attacker simply deleted files attached to existing releases and uploaded new ones under the same names, which anyone with write access to a repository can do. The download URLs didn’t change. OVHcloud’s advisory names the root cause directly: “the GitHub repository was not appropriately configured to ensure release immutability.” OVHcloud CEO Octave Klaba said the malware’s purpose was to “retrieve secrets from the disk,” according to BleepingComputer. Anyone who installed an affected build in that window should treat every secret on the machine as compromised.

Why the checksum file didn’t help

A checksums.txt attached to a release protects against a corrupted download. It doesn’t protect against someone who can change the release, because they can change the checksum file in the same step. That’s exactly what happened here.

The check that worked had one property the others lacked: the expected hash lived somewhere the attacker couldn’t write. The customer’s CI configuration recorded the SHA-256 when the version was first adopted. When the file changed, the hash no longer matched. Three kinds of checks have that property:

• A hash pinned in your own repository, recorded when you first adopt a version.
• A signature or attestation tied to an identity the attacker doesn’t control, such as a release key or the project’s build workflow.
• An immutable release, which stops the swap from happening in the first place.

The GitHub documentation on immutable releases says that once one is published, “its associated Git tag is locked to a specific commit and cannot be changed or removed,” and “all files attached to the release (such as binaries and archives) are protected from modification or deletion.” Immutable releases also get an automatic release attestation that records the tag, the commit SHA, and the assets. The catch is that the setting only protects releases created after it’s turned on, so v0.11.0 through v0.15.0 stayed editable.

What 37 popular CLIs offer

To see how common each protection is, on October 24 we checked the latest stable GitHub release of 37 command-line tools that are often installed from GitHub releases in CI. The list spans Kubernetes tooling, security scanners, linters, and general utilities. For each release we recorded the immutable flag from the GitHub releases API and which verification files were attached. We also queried GitHub’s attestations API with the SHA-256 digest of the Linux amd64 build.

Twelve tools combine an immutable release with a GitHub attestation: gh, yq, golangci-lint, GoReleaser, Trivy, cosign, TFLint, step, Syft, Grype, OPA, and now the OVHcloud CLI itself. For those tools, a release can’t be swapped, and you can verify the file you downloaded against the project’s own build.

Thirteen tools offered no independent check at all: kind, kustomize, k9s, act, ShellCheck, mkcert, Gitleaks, the Tekton CLI, stern, kubectx, Istio, the Cilium CLI, and Velero. Their releases had a checksum file or nothing, no signature, no attestation, no provenance file, and weren’t immutable. For these, a pinned hash in your own repository is the only check that would have caught an OVHcloud-style swap.

These are heuristics. We matched asset names, so a project that publishes signatures elsewhere, such as a container registry or a separate download site, may offer more than this shows. Helm is one example: its binaries are served from its own download site, and the GitHub release carries only signatures. The full results are published as JSON.

How to verify downloads in CI

Pin the hash when you adopt a version. Download the file once, compute its SHA-256, and commit the value next to the version number. Every later install checks against it. You can compute a hash in the browser with the hash generator, or with sha256sum locally.

# GitHub Actions step: install a pinned CLI version
- name: Install tool
  env:
    VERSION: "1.2.3"
    SHA256: "<hash recorded when this version was adopted>"
  run: |
    curl -fsSLo tool.tar.gz \
      "https://github.com/OWNER/REPO/releases/download/v${VERSION}/tool_linux_amd64.tar.gz"
    echo "${SHA256}  tool.tar.gz" | sha256sum --check --strict
    tar -xzf tool.tar.gz tool

Verify attestations where they exist. For tools that publish GitHub artifact attestations, the GitHub CLI checks them with one command: gh attestation verify tool.tar.gz -R OWNER/REPO. The attestation links the file’s digest to the workflow run that built it. A file uploaded by hand from a stolen account won’t have one.

Verify signatures against an identity, not a file on the same release. If a project signs its checksum file with Sigstore, verify the signature against the project’s expected signing identity before you trust the checksums. A signature checked only against a key or certificate attached to the same release is no better than the checksum file.

Don’t pipe install scripts into a shell in CI. The OVHcloud install script fetched the latest archive without checking a hash. Install scripts are convenient on a laptop. In CI, download a pinned version and check it.

Update hashes deliberately. When you upgrade, record the new hash in the same change that bumps the version, and get it from a verified source. Tools like Renovate can open those changes for you. The point is that a hash changes only when you change it.

If you maintain a CLI

The OVHcloud incident took a year to unfold: a malicious extension on a personal laptop in October 2025, stolen keys, and finally a release swap. A maintainer can’t control every contributor’s laptop, but can limit what a stolen account can do:

1. Turn on immutable releases for the repository or organization. The setting protects only releases created afterward, so cut a new release once it’s on.
2. Publish attestations from the release workflow. Use the actions/attest-build-provenance action or a tool such as GoReleaser, so every asset can be traced to a workflow run.
3. Keep release write access narrow. OpenSourceMalware reported that the account used here belonged to a contributor whose merged work was in OVHcloud’s documentation repository. Contributors who don’t cut releases shouldn’t be able to edit them.
4. Make the install script verify. If you ship a curl | sh installer, have it check an attestation or a signature, not only the checksum file next to the archive.

Recommended reading

• Hash generator and SHA-256 guide
• Kubernetes patch releases are running late
• The same YAML, eight different answers

Tags: #supply-chain, #github-releases, #ci, #sigstore, #attestations, #incident, #original-data