Hijacked Developer Account Used to Plant Stealer in OVHcloud CLI

A supply chain compromise targeted OVHcloud’s official command-line interface (CLI) tool, discovered on October 19th. The incident involved the injection of a secret-stealing binary via the GitHub account belonging to one of the company's developers. Compromised versions included v0.11.0 through v0.15.0; versions 0.10.0 and 0.16.0 were confirmed clean. The attack was initially exposed when a customer reported irregularities, leading to the blockage of compromised builds within about 94 minutes. OVHcloud attributed this vulnerability to GitHub’s release immutability option not being enabled, allowing an authorized user to modify published releases without triggering CI/CD checks.
The compromise potentially targeted developer and operations workstations by replacing binaries for common platforms only. An earlier suspected breach of the same contributor's account in March 2026 involved rewriting personal repositories with hidden loaders that appeared to query a known blockchain indicator. While researchers noted this potential prior compromise, they could not definitively link it to the October incident. Vulnerability exposure was limited to users who installed or updated the CLI via official scripts, Homebrew, or direct GitHub downloads during the affected window.

OVHcloud identified a supply chain incident involving its CLI tool on October 19th.
A hacker used the GitHub account of an OVHcloud developer to plant a secret-stealing binary.
Versions v0.11.0 through v0.15.0 are confirmed compromised.
Version 0.10.0 and version 0.16.0 were identified as clean.
The compromised release appeared at 14:47 Paris time and was blocked at 16:21.
The vulnerability stemmed from GitHub’s release immutability option not being enabled for the repository.
The malicious binary retrieved secrets from disk, targeting common platforms like macOS, 64-bit Linux, and Windows x8664.
An earlier account compromise was noted around March 2026 involving rewritten repositories and hidden loaders referencing Solana blockchain indicators.
CI/CD pipelines were not impacted by the immediate October event.
The compromised builds were uploaded over existing files of published releases.

Steelmanning this narrative requires acknowledging that sophisticated adversaries often exploit trust boundaries—the very mechanisms designed for collaboration, such as developer accounts and CI/CD pathways—to introduce malicious payloads into production artifacts. The strength of the reporting lies in the rapid response timeline (94 minutes) and the precise identification of which build versions were affected versus those that remained clean. The critical weakness identified by OVHcloud is a failure of configuration hygiene within GitHub, specifically the non-enforcement of release immutability, illustrating how protocol adherence forms the frontline defense against these vectors.
A pattern scan reveals an overlap between two distinct events: the October injection and the March account activity. This exhibits systemic reconnaissance—the attacker may not have executed the final payload during the first attempt but instead established persistence or tested initial access over months to refine their methodology for supply chain infiltration. The focus on credential harvesting, inferred from targeting developer workstations, positions this incident less as a random digital theft and more as targeted espionage aimed at gaining lateral movement into high-value corporate environments.
The unstated assumption fueling this narrative is that the defense against software tampering requires perfect configuration enforcement. However, what often remains unstated is the adversary's patience; successful supply chain attacks are not always single, hurried events but rather slow operations of access acquisition followed by carefully timed insertion. The costs are borne by users who rely on opaque automation for convenience—the trade-off between developer ease and security vigilance.
What institutional safeguards allow a permissioned individual to retroactively rewrite an official release without immediate oversight? If automated integrity checks fail, how quickly can the community or organization mobilize outside of traditional patch cycles to confirm system safety? What organizational protocols exist to differentiate persistent access (March) from active exploitation (October)?