www.it-connect.fr
OVHcloud CLI Binaires on GitHub Were Tampered With by an Infostealer
Did you install or update the OVHcloud CLI on Monday, October 19, 2026? For 94 minutes, the official binaries published on GitHub were replaced with a trojanized version designed to steal secrets stored on your machine's disk. Here's what you need to know.
For the record, ovhcloud-cli is the official command-line tool offered by OVHcloud. It lets you manage the hoster's services (VPS, Public Cloud, domains, IAM, etc.) from a terminal or a CI/CD pipeline. It is an open source tool available through the ovh/ovhcloud-cli GitHub repository, and it was this distribution channel that was targeted.
The alert came from Octave Klaba himself, in a message posted on his X account. "The 2:47 PM CLI release was compromised by a hacker. We detected it and blocked it at 4:21 PM," wrote OVHcloud's founder, who also thanked the customer who reported it. Versions v0.11.0, v0.12.0, v0.13.0, v0.14.0, and v0.15.0 are affected. By contrast, according to Octave Klaba, v0.10.0 is clean, as is v0.16.0, which was released following this security incident.
According to OVHcloud, the attacker used the GitHub account of one of the project's developers to add a binary that was able to retrieve secrets present on disk.
A SHA-256 fingerprint that no longer matches
The customer in question documented the incident in a public issue in the CLI repository. Their CI pipeline checked the SHA-256 fingerprint of the Linux arm64 archive: it changed without warning, and the builds failed. A good practice that paid off, and above all, probably prevented this incident from becoming more serious.
Their analysis shows that the files for versions v0.13.0 through v0.15.0 were replaced between 2:47 PM and 3:12 PM (Paris time), even though those versions had been published for several weeks. The OpenSourceMalware researchers add that releases v0.11.0 and v0.12.0 were also modified, which matches the full list published by Octave Klaba. For v0.15.0, the most recent one at the time, the Linux archives (arm64 and x86_64), macOS (arm64 and x86_64), and Windows x86_64 were substituted, along with the checksums.txt file.
The replacement binary was in no way an official build that OVHCloud could have pushed. Its build metadata shows that it was compiled locally, from a commit dated October 13, 2026, with changes that had never been published in the repository. More importantly, the checksums.txt file had also been rewritten: a user comparing their archive's hash against the one on the release page would have seen a match. Only a fingerprint recorded before the attack, such as the one from the reporter's CI pipeline, made it possible to spot the malicious change!
On OVHcloud's side, Romain Beuque confirmed the removal of the affected binaries at 4:21 PM, followed by the release of v0.16.0: a signed tag and, this time, an immutable release whose files can no longer be replaced.
A disabled GitHub option and the GlassWorm lead
In a second message posted on X later that evening, Octave Klaba announced that the analysis was complete. OVHcloud's CI/CD pipelines were not impacted. That is consistent with the attack scenario, because the trojanized binaries did not come from the official build chain.
The problem is elsewhere, and it comes down to a configuration issue: the release immutability option was not enabled on the repository. A sufficiently privileged account could therefore modify existing releases directly on GitHub at any time, without going through OVHcloud's CI/CD or triggering any control. "The option has been enabled. End of the incident." concluded OVHcloud's founder, who also apologized.
According to GitHub documentation, immutability only applies to releases published after it is enabled, unless they are republished. It therefore protects v0.16.0 and later, but not releases v0.10.0 through v0.15.0, which remain technically editable by an account with write access. An immutable release also receives a signed attestation, which makes it possible to verify the authenticity of its files with the GitHub CLI. All the more reason to move to v0.16.0.
For their part, the OpenSourceMalware researchers published a detailed analysis attributing the attack to the GlassWorm group. According to them, the account used belongs to a legitimate OVHcloud contributor with write access to the repository. However, several personal repositories belonging to that developer were modified in early March 2026 to add a preinstall.js script, automatically executed during npm install. That script queries the Solana blockchain to retrieve the address of its command server, via a wallet already identified in reports dedicated to GlassWorm.
The researchers remain cautious, however: nothing proves that the person who booby-trapped those repositories in March is the same one who replaced the OVHcloud CLI binaries in October, and how the credentials were stolen remains unknown. In any case, the activity of the HassenBF account is suspicious and questionable.
Are you affected? The reflexes to adopt
The risk concerns anyone, or any pipeline, that downloaded one of the compromised versions on October 19, 2026 between 2:47 PM and 4:21 PM. The official installation script (install.sh) downloads the archive from GitHub releases without checking its fingerprint: it is therefore affected, as is manual download and, in principle, the update command built into the CLI. Installation via go install or compilation from source is not affected, because tag v0.15.0 was not modified. According to OpenSourceMalware, the ovhcom/ovhcloud-cli Docker image was not affected either.
In any case, OVHCloud did not specify how many downloads of a malicious version of the tool occurred during this 94-minute window.
Keep in mind that the malicious code embedded in OVHcloud's CLI is designed to steal secrets from the computers on which it is deployed. The main recommendation is to rotate your secrets if you installed an infected version. This includes OVHcloud API credentials (the .ovh.conf file or environment variables), but also SSH keys, tokens for other cloud services or package registries, kubeconfig files, or .env files.
Ultimately, this scenario is reminiscent of Bitwarden CLI: in April, I published an article about the malicious Bitwarden CLI version distributed via NPM to steal sensitive information. A CLI installed on a workstation full of privileged access is the ideal target.
