OVHcloud CLI's October 2026 Supply-Chain Attack Explained: Swapped Release Files

You get different bytes from the same link, and nothing on the page tells you. The version number, the tag and the download address all stay the same, so most quick checks look fine.

That is what the OVHcloud CLI supply chain attack did on 19 October 2026. For about an hour and a half, the official GitHub downloads of several ovhcloud versions were a recompiled build. It carried an infostealer, a program that copies secrets off your disk. The source code on GitHub was never changed.

Picture a common setup. A developer on a small platform team in Pune sets up a new laptop on a Monday evening. They paste the one-line install command from the project's README, run ovhcloud login, and go back to work. The setup is made up, but the install path and the risk are real.

That laptop also holds cloud keys in a credentials file, an SSH key, a Kubernetes config and saved editor sessions. A stealer that runs once can read all of them. This guide follows that laptop from the download to the clean-up.

You need seven words. Each one gets a plain meaning and how it shows up in this incident.

• GitHub release: a named version of a project on GitHub, such as v0.15.0. It points to a Git tag and can carry notes and files.
• Git tag: a label fixed to one commit, which is one saved snapshot of the code. In this attack the v0.15.0 tag did not move, per issue 300.
• Release asset: a file attached to a release, such as ovhcloud-cli_Linux_x86_64.tar.gz. Assets are uploaded separately from the code.
• Checksum or hash: a short fingerprint calculated from every byte of a file. Change one byte and the fingerprint changes. SHA-256 and MD5 are two common recipes for it.
• Infostealer: malware whose job is to find secrets such as passwords, tokens and keys, and send them to the attacker.
• Indicator of compromise (IOC): a clue that proves or suggests an infection, such as a file fingerprint or a folder name.
• Attestation: a signed statement that a service makes about a file, such as which release or which build produced it. Anyone can check the signature later.

It was a swap of release files, not a change to the code. OVHcloud's advisory says a compromised developer GitHub account was used to replace the binaries of existing releases with malicious ones. It adds that the source code and build chain were not affected.

OVHcloud's advisory gives the window as 14:47 to 16:21 on 19 October 2026, in Central European Summer Time (UTC+2). For readers in India, that is 18:17 to 19:51 IST. The advisory counts about 250 downloads in that window.

The report itself is a good lesson. The reporter compared the replaced files with the originals and posted both SHA-256 fingerprints in issue 300. A maintainer replied that the files were deleted at 16:21 and that v0.16.0 was signed and immutable.

How you installed the tool decides whether this touches you. The table sorts the install methods from the project's README by what the sources say.

Our Pune laptop used the install.sh one-liner. Say the developer ran it at 19:10 IST (made up). That falls inside the window, and the script fetches the latest release, which at that time was v0.15.0.

Because the files on a release are uploaded separately from the code, and an account with enough access could replace one with a new file under the same name. The tag name, version and download address stayed the same.

A normal ovhcloud release is built by a CI pipeline, an automated system that builds and tests code on every change. OVHcloud's CEO said in a post on X, quoted by BleepingComputer, that those pipelines were not impacted. The bad files skipped the pipeline completely.

Issue 300 shows how. Go programs carry a stamp of how they were built, and the reporter read it from a replaced binary. It said the module version was v0.15.1-0.20261013083505-5ead8ef9b43d+dirty. That stamp means a build of a later commit, from 13 October, with uncommitted local changes.

The reporter also noticed the binary lacked the version setting that the project's release tool, GoReleaser, normally adds. Their reading: it was likely not built by the release pipeline. OpenSourceMalware, a community threat-intelligence group, reached the same view, as reported by BleepingComputer.

A picture helps here. A release is like a medicine box on a pharmacy shelf. The shelf label is the version, the box is the release and the strip inside is the binary. The batch sticker on the box is checksums.txt.

Someone with a staff key opened the box, swapped the strip and printed a new batch sticker. The shelf label was never touched. Where the picture breaks: a real box is one copy, while a release is served to everyone, so one swap reached every buyer at once.

The chain of causes behind the swap

No single mistake did this. The advisory and the reporting describe a chain, and breaking any link would have stopped or shrunk it.

1. 1

   A personal machine was infected

   The advisory says the developer installed an extension, color-picker-universal 2.8.91, on a personal MacBook on 20 October 2025. It does not say which app the extension was for.

2. 2

   Keys were stolen and kept

   The advisory says the releases were replaced using stolen keys. It also says the wallet used by that extension belongs to the GlassWorm threat actor.

3. 3

   The account still had release rights a year later

   The account could still edit releases of ovhcloud-cli. The advisory says OVHcloud then suspended it and reviewed every account with write access on the repository.

4. 4

   Releases were mutable

   The advisory names the root cause: the repository was not configured to ensure release immutability. The CEO said the setting was disabled.

5. 5

   Installers trusted whatever was there

   The install.sh script on the main branch, as of 28 October 2026, downloads the asset and runs no checksum check.

BleepingComputer also reports a third-party claim that the account had been compromised for more than half a year. That comes from OpenSourceMalware, not from OVHcloud's own advisory.

Because the same account that replaced the binaries could also replace checksums.txt, and the reporter says it did. A fingerprint only proves something when the attacker cannot change the fingerprint too.

Many projects publish a checksum file next to their binaries, and ovhcloud-cli's releases had one called checksums.txt. A careful installer downloads both, calculates the SHA-256 of the binary and compares. That catches a broken download or a tampered mirror, which is a copy of the files hosted somewhere else.

Pause and predict before running the demo below. It swaps a harmless text file standing in for a binary, then swaps the checksum file too. Which of the four checks will pass?

# Harmless demo: text files stand in for release assets
mkdir release
printf 'good build v0.15.0\n' > release/tool_Linux_x86_64.tar.gz
(cd release && sha256sum tool_Linux_x86_64.tar.gz > checksums.txt)
cp release/checksums.txt pinned_elsewhere.txt   # a pin kept in another place

(cd release && sha256sum -c checksums.txt)      # 1. original files

printf 'tampered build\n' > release/tool_Linux_x86_64.tar.gz
(cd release && sha256sum -c checksums.txt)      # 2. only the asset swapped

(cd release && sha256sum tool_Linux_x86_64.tar.gz > checksums.txt)
(cd release && sha256sum -c checksums.txt)      # 3. checksums.txt swapped too

(cd release && sha256sum -c ../pinned_elsewhere.txt)  # 4. the pin elsewhere

On GNU coreutils 9.4 the four checks print OK, FAILED, OK and FAILED. A failed check also prints a warning and exits with status 1. So the third check, the one that matches this incident, passes cleanly.

What just happened? Check 3 compared the new file against a fingerprint written by the same hand. Only check 4 used a fingerprint the attacker could not reach, and it caught the swap at once.

The Homebrew row needs a careful reading. The cask file, as of 28 October 2026, lists a SHA-256 for each platform's download, and Homebrew's Cask Cookbook calls it the checksum of the downloaded file. OVHcloud has not said whether Homebrew users were affected, so treat that row as how it should work.

Compare the binary's MD5 fingerprint with the advisory's list, and look for envchecker folders in your temp folder. Do both without running the binary. The advisory says not to run it, and an affected copy does its work on every run.

That rule rules out the usual reflex. Running ovhcloud version or ovhcloud --help to see the version could run the stealer again on an affected copy.

1. 1

   Find the file without running it

   On macOS or Linux, run command -v ovhcloud. It prints the path and does not start the program. On Windows, use where.exe ovhcloud in a terminal.

2. 2

   Calculate its MD5

   On Linux, run md5sum on that path. On Windows PowerShell, run Get-FileHash with -Algorithm MD5. On any machine with Python 3, the one-liner below works.

3. 3

   Compare with the advisory list

   Match the 32-character result against the table below. A match means you have a malicious binary.

4. 4

   Look for the leftover folder

   The advisory says each run creates a temp folder named envchecker followed by 9 or 10 digits, and never deletes it.

5. 5

   Check every machine

   Repeat on each laptop, build agent and container image where the CLI was installed during the window.

The advisory labels these as hashes of the ovhcloud binary itself, so hash the extracted program, not the downloaded .tar.gz or .zip archive. The script below does the comparison on macOS or Linux.

BIN="$(command -v ovhcloud)"     # path only, does not run it
H="$(python3 -c 'import hashlib,sys; print(hashlib.md5(open(sys.argv[1],"rb").read()).hexdigest())' "$BIN")"
echo "MD5: $H"
case "$H" in
  6f2f086239f3d88eb2750e871901927d|347e65eb7f2d78d1c6872690272a6cc3|\
  01f57206d37c28cf711677f612052913|301bff0b51980b9e76c93633e7cfd3bd)
    echo "MATCH: malicious binary from the advisory list" ;;
  *) echo "No match with the advisory list" ;;
esac

# leftover folders: prints nothing if none exist
find "${TMPDIR:-/tmp}" /tmp -maxdepth 1 -type d -name 'envchecker-*' 2>/dev/null | sort -u

Expect one line starting MD5: followed by 32 hexadecimal characters, which is 128 bits. Then you get either MATCH or No match. We ran this comparison on harmless test files only, including a forced match to test the MATCH branch.

Where should you look for the folder? The advisory only says the temp folder. On macOS and Linux, check the folder in TMPDIR and also /tmp. On Windows, check the folder in the TEMP environment variable, for example with Get-ChildItem $env:TEMP -Filter envchecker-*.

Beginners can stop here if their check came back clean. The rest explains what to do on a match and how GitHub's newer features close the gap.

Treat every secret on that machine as stolen, change or revoke them, then remove the binary and install v0.16.0 or newer. That is the order the advisory gives, and the CEO's short version was to change all the secrets on your disk.

1. 1

   Rotate secrets first

   Change or deactivate credentials for every service the advisory lists. We would do this from another machine, because the advisory does not say whether anything else was left running.

2. 2

   Delete the binary

   Remove the matched ovhcloud file. Deleting it does not undo what it already copied.

3. 3

   Install a clean version

   Install v0.16.0 or later. Check its fingerprint against a source the release uploader cannot edit.

4. 4

   Check for the wider infection

   The advisory says the stealer reaches into many tools. Review cloud audit logs for unknown access since 19 October 2026.

The advisory's target list covers more than OVHcloud keys. It names AWS, Google Cloud, Azure and DigitalOcean credentials, Docker and Kubernetes configs, Terraform, npm, the .netrc file and global Git config. It also names SSH keys and the local databases of several code editors and AI coding assistants.

Back on the Pune laptop, the folder check printed one envchecker folder (made up). So the developer revoked the cloud keys, replaced the SSH key on every server, reset the Kubernetes credentials and signed out of editor sessions. All of that took far longer than the roughly 93 minutes the malware was online.

They lock a release's assets and its Git tag once it is published. GitHub's docs say assets cannot be modified or deleted, and the tag is locked to one commit.

Three details matter for incidents like this one. Each comes from GitHub's documentation as of 28 October 2026.

• Only future releases are covered. The settings page says immutability will only apply to future releases, so v0.11.0 to v0.15.0, published before the switch, keep their old rules.
• Title and notes stay editable. You can still change a release's title, notes and its pre-release or latest flag. An attacker with access could still edit a download link written in the notes.
• Deleting is allowed, but the tag name is burned. You can delete an immutable release and then its tag, but the same tag name can never be reused. That even holds after deleting and recreating the repository.

Publishing an immutable release also creates a release attestation. GitHub describes it as a cryptographically verifiable record of the release tag, the commit SHA (the commit's unique ID) and the release assets. Users check it with the GitHub CLI, called gh.

GitHub's docs give two commands. The first checks that a release exists and is immutable, and the second checks that a local file exactly matches a release asset. Swap in your own tag and file path.

# Is this release immutable, with a valid attestation?
gh release verify v0.16.0 -R ovh/ovhcloud-cli

# Does my downloaded archive exactly match the published asset?
gh release verify-asset v0.16.0 ./ovhcloud-cli_Linux_x86_64.tar.gz -R ovh/ovhcloud-cli

We checked these commands and their flags in the help text of gh 2.89.0. We could not run them against OVHcloud's releases from our test machine, so we do not show their output. The docs add that verify-asset cannot check GitHub's auto-made source zip or tarball.

For maintainers, the docs suggest one habit. Create the release as a draft, attach every asset, then publish. Otherwise you lock a release before all its files are in.

A release attestation proves which bytes were published. An artifact attestation goes further and proves which workflow built them, from which commit. Neither proves the code is safe.

Artifact attestations tie a file to its build

An artifact attestation is created inside a GitHub Actions workflow. GitHub's docs say it records the workflow, the repository, the commit SHA and the triggering event. For public repositories, it is also written to a public transparency log, an append-only record anyone can search, run by Sigstore, an open-source signing project.

permissions:
  id-token: write
  contents: read
  attestations: write

steps:
  # ... your build step produces dist/ovhcloud ...
  - name: Generate artifact attestation
    uses: actions/attest@v4
    with:
      subject-path: 'dist/ovhcloud'

A user then runs gh attestation verify on the file with -R and the repository name. A binary built on someone's laptop, like the swapped ones, would have no matching attestation. The gh help text adds that you should ideally also pin the signer workflow with --signer-workflow. With only -R, the check accepts any workflow in that repository, which someone with push access could add. GitHub's docs still warn that attestations are not a guarantee that an artifact is secure.

Reading a Go binary's build stamp without running it

The ovhcloud CLI is written in the Go programming language, and Go normally embeds build information in the binaries it builds. The command go version -m prints it by reading the file. Issue 300's reporter used this kind of stamp as a clue.

We built a tiny harmless program twice on Go 1.24.7: once from a clean Git tag, and once after editing a file without committing. Here are the relevant lines.

== clean build at tag v0.1.0
	mod	example.com/demo	v0.1.0
	build	vcs.modified=false
== build with an uncommitted change
	mod	example.com/demo	v0.1.0+dirty
	build	vcs.modified=true

The +dirty suffix and vcs.modified=true are the same signals the reporter quoted. To prove the command does not run the file, we also read a macOS arm64 binary and a Windows binary on a Linux x86_64 machine. Both printed their build details, though Linux could not run either.

A stamp is a clue, not proof. A careful attacker can build with -buildvcs=false or from a clean checkout. Our run with -buildvcs=false printed no vcs lines at all.

Lock what you publish, sign where it came from, and keep the right to change releases with as few accounts as possible. The table splits the steps by role.

OVHcloud's own list of next steps, as of its advisory, includes signing all commits and merges, immutability for all releases and linking release publishing to its central identity system. Two of them, immutability and tighter control of who can publish, match rows in the table.

Frame it as a trust chain from source to user, then show where the chain had a gap.

1. 1

   State the incident in one line

   Existing release binaries of a CLI were replaced with a stealer through a stolen account, while source and CI stayed clean.

2. 2

   Draw the chain

   Source, CI build, release assets, installer, user machine. Mark the release step as the point the attacker joined.

3. 3

   Explain why checksums failed

   The checksum file lived in the same mutable release, so whoever could swap the binary could swap the fingerprint.

4. 4

   Name the controls

   Immutable releases lock assets after publishing. Release attestations prove the published bytes. Artifact attestations prove which workflow built them.

5. 5

   Cover detection and response

   Hash comparison without running, IOC folders, and secret rotation in order, with the window and download count as scale.

6. 6

   Close with the limits

   Immutability covers only future releases. Attestations prove origin, not safety. Account hygiene still matters.

Rough numbers help. The window was about 1 hour 33 minutes with about 250 downloads, per the advisory. One stolen account and one disabled setting were enough.