Hackers compromised the GitHub account of an OVHcloud developer and used it to distribute malicious files through the company’s official command-line tool releases.
The October 19, 2026, supply chain attack targeted users downloading the OVHcloud CLI, with malware designed to collect secrets stored on their computers. A customer spotted suspicious release changes and alerted the cloud provider, which blocked the malicious files within 94 minutes.
OVHcloud CEO Octave Klaba said the affected releases were v0.11.0, v0.12.0, v0.13.0, v0.14.0, and v0.15.0. He identified v0.10.0 as clean and announced a safe v0.16.0 release. That replacement is now available on the project’s official GitHub releases page, where it is marked as immutable, meaning its published release files cannot be changed.
OVHcloud Supply Chain Attack
According to Klaba’s account, the compromised files appeared at 14:47 and were detected and blocked at 16:21. OVHcloud’s initial checks found no other affected repository. Those findings limit the confirmed scope to the CLI project, rather than establishing a wider breach across the company’s GitHub organization or cloud platform.
The attacker used an existing developer account to add a malicious binary to the software distributed through GitHub. This placed the threat inside a trusted download location, giving users little reason to suspect that a routine CLI download could expose local credentials. OVHcloud has not explained how the developer account was first compromised.
The customer’s report raised concerns about release files being replaced with a “dirty build” of a later commit. In software builds, that label generally signals changes beyond the recorded source revision. The public issue listing identifies the report as issue #300, covering replaced assets for v0.13.0 through v0.15.0. OVHcloud’s warning named two additional affected versions.
The customer also questioned the account behind the changes and asked whether release files should be locked against replacement. They said they had switched to building through the Go module proxy while seeking clarification. Their report was public because the repository lacked a private vulnerability reporting channel.
Klaba described the added program as a binary whose job was to retrieve secrets from disk. He said its quality was poor but warned that it could still achieve its purpose. The available disclosure does not establish which files it searched, where collected data was sent, or how many users executed the malicious downloads.
The CLI’s normal role makes this threat especially serious. OVHcloud documents the tool as a way to manage cloud services, account resources, and automated workflows. Its supported authentication methods include a local .ovh.conf file containing credentials, alongside environment variables for application keys, application secrets, and consumer keys.
Those documented credential locations explain why a compromised administration tool can create risks beyond the downloaded program itself. However, they are not a confirmed list of this malware’s targets. Until OVHcloud publishes its technical findings, specific claims about stolen SSH keys, browser passwords, persistence, or attacker infrastructure would go beyond the evidence.
The incident fits the broader pattern covered in Cybersecuritynews.com’s reporting on trusted software updates used to steal developer and cloud credentials. Attackers can use stolen publishing access to turn familiar software delivery channels into routes for credential theft, without needing users to visit a fake website.
OVHcloud urged users who downloaded the CLI during the incident to update it immediately or delete it. Klaba also advised affected users to change all secrets stored on disk. Rotation is important because replacing the malicious program does not cancel credentials that may already have been copied.
Organizations investigating possible exposure should identify which machines downloaded and ran affected files, preserve available evidence, and review account activity tied to potentially exposed credentials. Their response should extend beyond OVHcloud credentials if other secrets were accessible on those machines. The company’s warning covers local secrets broadly, not only its own service keys.
A related GhostAction GitHub credential theft campaign shows why repository access deserves close attention. That campaign used stolen accounts to introduce malicious workflows under trusted identities. No evidence currently links it to the OVHcloud incident. For OVHcloud users, the immediate priorities remain replacing affected downloads and renewing potentially exposed secrets while the company continues its malware investigation and publishes further technical findings.