OVHcloud CLI releases hijacked to steal secrets via GitHub account compromise

On Monday, October 19, attackers compromised a contributor’s GitHub account and replaced download archives for five existing releases of the OVHcloud command-line interface. The malicious binaries, designed to steal secrets from local disks, were live on GitHub for 94 minutes before the cloud provider removed them and issued a clean, immutable release.

What happened

The incident targeted versions v0.11.0 through v0.15.0 of the OVHcloud CLI, which were published between April 14 and September 16. Between 12:47 and 14:21 UTC, an attacker with access to a contributor account deleted the original archive files and uploaded new ones containing malware. The attacker also replaced the checksums.txt file to ensure the published hashes matched the malicious binaries, bypassing basic integrity checks that rely solely on those provided checksums.

OVHcloud founder Octave Klaba confirmed that the source code, release tags, and internal build pipelines remained untouched. The malicious files were simple Go builds of a later commit, uploaded directly to the GitHub release pages. The company responded by deleting the swapped archives and publishing version v0.16.0 as an immutable release, a GitHub feature that prevents further modification of release assets. The compromised contributor had merged work into the documentation repository but was not a public member of the organization.

How it works

The attack exploited the ability of users with write access to modify existing GitHub releases when immutability is not enabled. This setting, generally available since October 2025, locks release files and tags but only protects releases created after activation. OVHcloud had not enabled this option for the affected releases, allowing the attacker to swap binaries without triggering any CI/CD pipeline checks or workflow runs.

The malware itself was a secret-stealer targeting credentials stored on the disk, such as those in ~/.ovh.conf or environment variables. Researchers from OpenSourceMalware linked the compromised account to GlassWorm, a campaign known for hiding code in invisible Unicode characters. While no copy of the October binary has been publicly analyzed, four personal repositories associated with the account showed force-pushes in March containing loaders consistent with GlassWorm tactics.

Key details

• Compromised versions: v0.11.0, v0.12.0, v0.13.0, v0.14.0, and v0.15.0 are considered compromised; v0.10.0 is clean.
• Affected platforms: macOS (x86_64, arm64), Linux (x86_64, arm64), and Windows (x86_64). Linux i386, Windows i386, Windows arm64, and WebAssembly builds were untouched.
• Exposure window: 12:47 to 14:21 UTC on October 19, 2026.
• Detection method: Malicious binaries show a pseudo-version like v0.15.1-0.20261013083505-5ead8ef9b43d+dirty and contain -ldflags="-s -w", whereas genuine releases show tag numbers and no ldflags line.
• Safe installation paths: Homebrew users were protected because casks pinned original SHA-256 hashes, causing mismatched downloads to fail. Docker images and go install methods were also unaffected.
• Malicious hash: The SHA-256 for the swapped v0.15.0 Linux arm64 archive is 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb.

Why it matters

This incident highlights the fragility of supply chain security when release immutability is not enforced. Many developers rely on install scripts or direct downloads from GitHub releases without verifying cryptographic signatures or pinning hashes. The official OVHcloud install script, for example, downloads the latest archive without checking a hash, making any user who ran it during the 94-minute window vulnerable. Similarly, CI jobs fetching archives without pinned hashes would have silently installed the malicious version.

For engineering teams, this serves as a critical reminder that trust in a repository’s contributors must be balanced with technical safeguards. Even if a build pipeline is secure, direct manipulation of release assets can bypass it entirely. The fact that Homebrew users were protected demonstrates the value of package managers that enforce hash pinning, while those using manual installs or custom scripts faced higher risk. Rotating secrets is now mandatory for anyone who may have executed the compromised binary, as the malware likely exfiltrated all readable secrets from the host machine.

What you can do

• Rotate every secret stored on machines that may have run the compromised CLI, using a different, clean machine to perform the rotation.
• Remove the current OVHcloud CLI binary and install version v0.16.0, which is published as an immutable release with attestation.
• Verify downloaded archives using the GitHub CLI command gh release verify-asset v0.16.0 FILE to ensure integrity.
• Enable release immutability on your own GitHub repositories to prevent unauthorized modification of existing release assets.
• Pin SHA-256 hashes in CI/CD pipelines and install scripts instead of relying on dynamic latest tags or unchecked downloads.
• Audit contributor access levels and enforce multi-factor authentication to reduce the risk of account compromise.