OVHcloud’s command-line interface (CLI) was compromised when attackers hijacked a contributor’s GitHub account to replace legitimate download archives in five existing CLI releases. The malware-infected builds, designed to steal secrets stored on affected machines, were live briefly on October 19, 2026. The tampered files were available for 94 minutes, from 12:47 to 14:21 UTC, targeting macOS, Linux (x86_64 and arm64), and Windows x86_64 users. The malicious update path relied on missing hash validation.
Details of the Compromise and Exposure
The attacker replaced archives and checksum files for versions v0.11.0 through v0.15.0—released between April 14 and September 16—with malicious builds that matched the updated hashes. These swaps affected macOS (both arm64 and x86_64), Linux (arm64 and x86_64), and Windows x86_64 binaries. Builds on Windows i386, Windows arm64, Linux i386, and WebAssembly were left untouched. Users who installed or updated the CLI during the attack window via the install script or from the GitHub release page are potentially exposed. Others using Homebrew, go install, or Docker were not impacted.
How to Detect and Limit the Damage
Signs of the malicious build include a pseudo-version module line (showing a commit from October 13, not matching tagged version v0.15.0), a recorded commit hash of 5ead8ef9b43d instead of 760fd72, and the presence of “-ldflags=\”-s -w\””—flags atypical for a genuine OVHcloud release.
If your system was exposed, OVHcloud recommends rotating all secrets readable from the device and uninstalling the compromised binary. Then, switch to v0.16.0, which was published with immutable release settings and a signed release attestations ensuring file integrity. Users can verify legitimate archives using GitHub’s “verify-asset” feature.
Root Cause: Missing Release Immutability
The root issue was identified as OVHcloud’s failure to enable GitHub’s release immutability setting—a feature rolled out in October 2025 but only protecting releases created after its activation. Because it was disabled, someone with write access could alter existing release files directly without triggering any CI or security checks. This gap allowed the malicious archives to be uploaded to older tags. The setting has since been enabled, though only new releases are fully protected.
The compromised GitHub account belonged to a contributor with write access through documentation repositories and is not listed among OVHcloud’s public members. The exact method of account takeover has not been disclosed. A customer’s continuous integration (CI) check caught the swap due to a mismatched SHA-256 hash, triggering a public issue and prompting a cleanup. Bad files were removed around 14:21 UTC, followed by a fresh, secure v0.16.0 release later that evening.
Security researchers also connected the account to the GlassWorm campaign, which uses invisible Unicode characters and Solana wallet transactions to smuggle code. The overlap is based on shared repository behavior and the same account’s involvement, though no direct evidence has tied stolen tokens or walled-off infrastructure from this incident to that larger campaign.
OVHcloud continues to investigate and has pledged a full postmortem.
Meantime, this incident underlines the risks inherent in supply chain attacks—especially when build pipelines and release integrity checks are lax. For devs, operators, and security teams: always enable immutability or signed-release options where available, pin hashes, verify artifacts, and assume compromised binaries can read credentials. The damage potential runs from API keys to SSH private keys, depending on what’s stored and how isolated your environment is. Watch closely how OVHcloud handles remediation and whether this prompts broader industry adoption of stronger release hygiene practices.
