OVHcloud CLI Attack: Malicious Software Replaced Legitimate Releases in Supply-Chain Breach

A compromised developer account allowed an attacker to distribute software designed to steal credentials through OVHcloud's official command-line tool. The incident highlights why verifying a software download is not the same as verifying the system that published it.

On 19 October 2026, an attacker used a compromised GitHub developer account to replace release files for five versions of OVHcloud's command-line interface (CLI), a tool used to manage the company's cloud services. According to OVHcloud's security advisory, the malicious files were available for approximately 94 minutes before being removed.

Versions 0.11.0 through 0.15.0 were affected. The malicious binaries were designed to collect sensitive files and credentials stored on a user's machine, potentially including cloud access keys, SSH keys, Docker configuration and Kubernetes credentials. OVHcloud said its source code and build pipeline were not compromised; the attacker modified previously published release assets instead.

The company removed the affected files, released a clean version 0.16.0 and enabled immutable releases to prevent published assets from being silently replaced. Its advisory also reported approximately 250 downloads during the exposure window. That figure does not establish how many downloads executed the malicious binary or resulted in stolen credentials.

This incident illustrates why investigators should examine the software artifact itself, not simply trust its download location.

A digital forensic investigation would begin by identifying potentially affected systems through installation records, endpoint telemetry, shell history, CI/CD logs and download timestamps. Investigators could then calculate cryptographic hashes of recovered binaries and compare them against the known malicious hashes published in the vendor's advisory.

Binary metadata can provide additional clues. In this case, the advisory describes build information that differed from the expected tagged release. Comparing build identifiers, version metadata, release timestamps and GitHub audit records can help establish whether a binary was produced through the expected release process or uploaded through an alternative path.

Investigators would also examine execution artefacts, temporary directories, process activity and network telemetry for evidence that the malware ran, collected sensitive files or transmitted data externally. The absence of an obvious malware alert does not prove that a system was unaffected, particularly if relevant logs were not retained.

A critical distinction remains: a compromised download does not automatically prove credential theft. Investigators must establish whether the file was downloaded, executed, and able to access sensitive information. They should also determine which credentials were present and whether subsequent activity indicates misuse.

OVHcloud's advisory identifies a compromised developer account as the route used to alter the releases. Security researchers have linked the account to earlier activity associated with GlassWorm, but that connection should not be treated as definitive proof that the same actor conducted every related incident.

The case demonstrates how a brief release-window compromise can create a much longer investigative problem. Establishing the affected systems, reconstructing execution and determining whether credentials were exposed are essential steps in understanding the real impact of a software supply-chain attack.