On October 19, download files attached to five published releases of OVHcloud’s official command-line interface (CLI) contained a modified build designed to steal secrets and files from the computer running it. According to the security advisory OVHcloud published on October 20, the malicious files were available for 1 hour 33 minutes, and they were downloaded about 250 times. They were uploaded through the compromised GitHub account of an OVHcloud developer. OVHcloud removed them that afternoon and published a new release, v0.16.0, that evening.

The CLI manages OVHcloud products and account resources from a terminal and can run inside CI/CD pipelines. The tampering came to light when a customer’s CI build failed because a downloaded file no longer matched its pinned checksum.

Key facts

  • Affected builds: v0.11.0 through v0.15.0 for macOS, Linux x86_64 and arm64 and Windows x86_64, downloaded between 12:47 and 14:21 UTC on October 19.
  • Risk: OVHcloud advises anyone who downloaded or updated the CLI in that window and ran it to treat the secrets on that computer as compromised.
  • Check: without running the binary, compare its MD5 hash with those listed in the advisory, or look for an envchecker folder in the temporary directory.
  • Root cause: OVHcloud traces the account compromise to an extension installed on the developer’s personal MacBook in October 2025, which it links to the Glassworm threat actor.

How a Pinned Checksum Exposed the Swap

According to the advisory’s timeline, the first file replaced was the macOS build of v0.15.0, at 12:47 UTC. By 12:57 UTC all affected v0.15.0 binaries had been swapped, and by 13:30 UTC those of v0.11.0 through v0.14.0 as well. The replaced files were the macOS, Linux x86_64 and arm64 and Windows x86_64 builds. According to the customer’s report, the checksums.txt files of v0.13.0 through v0.15.0 were replaced as well.

The file that exposed the swap was the Linux arm64 archive of v0.15.0, whose SHA-256 checksum the customer’s CI had pinned. The customer reported it in a public GitHub issue at 13:50 UTC, because the repository had no private vulnerability reporting channel. OVHcloud has since enabled one.

OVHcloud began investigating at 13:57 UTC, started scanning all its GitHub repositories at 14:20 UTC and removed every malicious binary at 14:21 UTC. According to the advisory, the source code and build chain were not affected, and no other repository was altered.

Linux Kernel Flaw PwnEscape Lets a Virtual Machine Read Its Host’s Memory. Upstream Fixes Are Out.

Who Received the Replaced Files

The installation command in the project’s README pipes a script from GitHub into the shell, and the script downloads the archive of the latest release without checking a checksum. Manual downloads from the release pages fetched the same files, with no automatic checksum check. So did the CLI’s built-in upgrade command, available since v0.12.0, which on macOS and Linux replaces script-installed or manually installed copies with the latest release’s archive, also without a checksum check. During the window, each of these routes could fetch a replaced archive.

The Homebrew cask, generated by OVHcloud’s release pipeline, still listed the SHA-256 checksums recorded at the v0.15.0 release on September 16. Homebrew checks each download against them, so a replaced archive would not have passed. Installing with go install builds from the source code, which the advisory lists as unaffected.

What the Malicious Build Targeted

According to the advisory, the malicious binaries were the original CLI recompiled with an embedded stealer module named envchecker. Its targets include credentials and configuration for AWS, Google Cloud, Azure and DigitalOcean, SSH keys, Kubernetes, Docker, Terraform and npm configuration, .netrc and Git settings, and local data from code editors and AI coding assistants, including VS Code, Cursor and Claude.

On each run, the binary copies the collected files into a new folder in the temporary directory, named envchecker followed by nine or ten digits, and archives it for exfiltration. The exfiltration relies on Solana RPC calls and an upload server, both listed among the advisory’s indicators of compromise. The folder is never deleted, so its presence shows that the binary ran.

OVHcloud’s advice for anyone who downloaded or updated the CLI between 12:47 and 14:21 UTC on October 19 and ran it is to change or deactivate the secrets for all relevant services, delete the compromised binary and install v0.16.0. To check a binary without running it, the advisory lists the MD5 hashes of the five malicious builds.

OVHcloud Unbundled the IP and the Disk. Hetzner Took Its Cheapest Line Off Sale. The Memory Bill Has Reached the Price List.

An Extension on a Personal Laptop

OVHcloud traces the compromise to the developer’s personal MacBook, where the extension color-picker-universal 2.8.91 was installed on October 20, 2025. The extension uses a Solana wallet that OVHcloud describes as belonging to the Glassworm threat actor, and the same wallet appeared again in March 2026, when several of the account’s personal repositories were compromised. The release files were replaced with stolen keys rather than from the MacBook itself, and as far as OVHcloud knows, the developer’s OVHcloud laptop was not compromised.

OVHcloud’s production CI/CD runs on internal systems rather than on GitHub and was not compromised, according to the advisory. The company’s GitHub organization, used for projects it publishes, requires two-factor authentication and lets developers attach personal accounts.

Immutable Releases Across OVHcloud’s GitHub

OVHcloud identifies the main issue as the repository not being configured for release immutability and has since applied that setting to all its repositories. GitHub’s documentation notes that the setting applies only to future releases, and of the project’s 18 releases, only v0.16.0 is marked immutable. For an immutable release, GitHub locks the tag and attached files after publication and adds a release attestation, a cryptographically verifiable record of the tag, commit and files. OVHcloud’s next steps include systematic signing of commits and merges and a review of all publication pipelines and GitHub accounts.

For hosting providers that distribute their own tools, plugins or installers through GitHub releases, the incident involved two controls: immutable releases, which OVHcloud now applies across its organization, and a checksum pinned outside the release, which is how the change was detected.