OVHcloud CLI: five releases hijacked with a secret stealer
Using a developer’s GitHub account, an attacker replaced OVHcloud CLI binaries from 0.11.0 to 0.15.0: who is affected and what to do right now.

On 19 October 2026 an attacker used the GitHub account of an OVHcloud developer to replace the binaries of five already published releases of the OVHcloud CLI, the open-source command-line tool administrators and developers use to manage and automate the French provider’s cloud and hosting services. In place of the original files, a binary appeared whose job, according to founder and CEO Octave Klaba, is to retrieve secrets from the disk. The incident was covered by BleepingComputer, SecurityWeek and The Hacker News; the technical details below come from Klaba’s statements on X and from the analysis of the community platform OpenSourceMalware, as reported by the first two outlets.
What happened
The compromised versions are v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. Version 0.10.0 and the new 0.16.0 are clean. According to Klaba, the compromised release appeared at 14:47 (Paris time) and was blocked at 16:21, after a customer reported it: a window of about 94 minutes. OpenSourceMalware, cited by SecurityWeek, says a user publicly flagged the tampering on GitHub after an automated hash check failed.
The cause given by OVHcloud is a configuration issue: GitHub’s release immutability option was disabled. An account with the right permissions could therefore modify existing releases directly, without going through the CI/CD pipeline. Klaba notes that the pipelines, with unit tests, functional tests and CVE detection, were not affected. The option is now enabled and, according to BleepingComputer, OVHcloud considers the incident resolved.
Klaba describes the binary as “poor quality, but it can go all the way”, and asks anyone affected to clean up the system and change all the secrets on their disk.
Technical details
According to OpenSourceMalware, the attacker did not use the CI/CD: they uploaded locally built binaries over the original files of releases that had already been published. Only builds for the most common platforms were replaced, which the researchers see as a sign that the goal was harvesting credentials from developer and operations workstations:
- affected: macOS (Intel and ARM), Linux x86_64 and ARM64, Windows x86-64, if installed or updated during the window via the official install script, Homebrew or a direct GitHub download;
- not affected: anyone who built from source, used Go’s install command or uses the official Docker image.
The payload has not been analysed: OpenSourceMalware could not obtain a sample before OVHcloud deleted the files. As a result, there are no public indicators (hashes, domains, addresses) for the binary distributed with the CLI.
The account belongs to a legitimate OVHcloud contributor and, according to the researchers, had been compromised since at least March 2026: on 5 March the history of four of its personal repositories was rewritten by a script, and three of them gained a hidden loader (preinstall.js). The loader’s next stage queries the Solana blockchain (a dead drop in the transaction memo field) to find where to download the payload, using a wallet that is a known indicator of GlassWorm, the campaign active since late 2025 against the VS Code, OpenVSX, GitHub and npm ecosystems.
The GlassWorm link should be read with caution: the researchers themselves write that the same actor being behind both the March account compromise and the October CLI attack is their inference, and OVHcloud has not mentioned GlassWorm in its statements.
In our reading, the relevant MITRE ATT&CK techniques are T1195.002 (Compromise Software Supply Chain), T1078 (Valid Accounts), T1552.001 (Credentials In Files) and, for the loader in the personal repositories, T1102.001 (Dead Drop Resolver).
Impact for European and Italian companies
OVHcloud is one of the main European cloud providers, and many Italian companies host services and infrastructure there. The CLI runs on the most privileged machines: administrator and developer workstations, management servers and CI/CD runners. These are the same machines that hold API keys, SSH keys, tokens and configuration files for other environments, so the exposure can extend well beyond the OVHcloud account.
For NIS2 entities, supply chain and development security is one of the required measures: a malicious binary run on a workstation with infrastructure access should also be assessed as a potentially reportable incident, depending on the access actually obtained.
What to do right now
- Find the installations: look for the OVHcloud CLI on workstations, servers and runners, and check whether it was installed or updated on 19 October between 14:47 and 16:21 Paris time (12:47–14:21 UTC) via the official script, Homebrew or a GitHub download. Container images built in that window by downloading the binary count too.
- Replace the binary with 0.16.0, or build from source. If you have 0.11.0–0.15.0 and don’t know when it was downloaded, treat it as suspicious.
- Treat every secret as compromised on a machine that ran an affected binary, as Klaba asks: OVHcloud and other cloud API credentials, SSH keys, Git and registry tokens,
.envfiles and configurations. Rotate them and revoke the old ones. - Check how credentials were used since 19 October in your providers’ logs: logins from unusual addresses, new keys, infrastructure changes.
- Clean or reinstall the affected machines: without an analysis of the payload, it is not known whether it leaves persistence.
- Harden your supply chain: pin tool versions and verify hashes before installing, as the user who discovered the tampering did. If you publish software on GitHub, enable release immutability, require MFA for contributors and monitor changes to the files of already published releases.
How ARXDOME helps
With its agent, ARX Sentry collects the software and process inventory of Windows, Linux and macOS computers and servers, so you can quickly find the machines where the CLI is installed. If a machine is suspicious, ARX Shield lets you isolate it from the network while it is cleaned and its secrets are rotated.
Last updated:


