Updated October 21, 12:50 BST with post-mortem details.
OVHCloud CEO Octave Klaba said a repository for the Command Line Interface (CLI) to manage the European cloud firm’s services was briefly compromised in a supply chain attack that was reported to the company by a customer today (October 19.)
A malicious version of the software released by the hacker was spotted and blocked in 94 minutes. (The compromised versions of the OVHCloud CLI are v0.11.0 v0.12.0 v0.13.0 v0.14.0 v0.15.0. Version v0.10.0 and the upcoming 0.16.0 are clean.)
The cloud provider appears to have got lucky: A single repository was hit.
Posting on X, Klaba said: “We just finished the initial checks and no other repo is affected. We also traced the incident. The hacker used the GitHub account of one of the developers and added a binary whose job is to retrieve secrets from the disk.
He added: “The quality of the binary is poor but it can go all the way [sic].”
Klaba added:
“If you are affected, please change all the secrets on your disk. We are continuing the research on the binary and we will publish additional details shortly.”
OVHcloud CLI repository is not a hive of activity, having seen just 14 commits over the past month. The associated issue on the repository appears to be this one.
OVHcloud said: "Our investigations led to the account of a developer which has been used to replace the releases' binary. The compromission [sic] took place months before when the developer installed the extension color-picker-universal 2.8.91 on 2025-10-20 on its personal MacBook. When looking at the extension, the Solana wallet BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC is used to make RPC calls. This wallet is known as belonging to the Glassworm threat actor.
A persistent NodeJS service has been registered (plist) communicating with 162.33.177[.]177."
In March 2026, several personal repositories of this account have been compromised as well and the wallet BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC has been once again used.
The replacement of the OVHcloud CLI releases has not been performed by the personal MacBook of the developer but instead by using the stolen keys.
The OVHcloud laptop of the developer has not been compromised as far as we know at that time.
The customer raising the issue commented that the account making the malicious changes, HassenBF “is not a public member of the ovh org and doesn't show up among the repo's contributors. That may just be a private membership, but together with the dirty build it seemed worth flagging rather than assuming,” they said.
“If this was a legitimate rebuild, it would help to know why, and to have release assets treated as immutable (or new versions published instead). If it wasn't, the affected assets should probably be pulled. We have switched to building from the module proxy in the meantime. There was no private vulnerability reporting channel enabled on this repo, hence a public issue. Happy to move it elsewhere if you prefer.”
OVHCloud customers may be concerned that it took a customer to spot the incident.
More importantly, releases should come only from a locked-down build pipeline that has to be approved before it publishes. Rudimentary software security controls appear to have been missing at OVHcloud. If there is a silver lining, it is that it was spotted fast, communication has been clear and come from the CEO himself.
Updated: OVHcloud has published a post-mortem here. As it notes:
"The main issue was that the GitHub repository was not appropriately configured to ensure release immutability. This misconfiguration has been corrected immediately and the repository is not longer at risk. The same configuration has been applied to every repositories."
Developers, their credentials and their accounts are increasingly targeted by attackers. They can be a beachhead from which to launch the upstream supply chain attacks of the kind that have plagued the industry and exploded in recent years.
As Sonatype noted in its 2026 State of the Software Supply Chain report (writing about a broader problem than OVHcloud’s incident today):
“Attackers are perfecting social and technical mimicry to target and exploit developers making development decisions fast and with incomplete information… Attackers know developers under deadline pressure are unlikely to pay detailed attention on [sic] every dependency. If a package “looks right” with mostly comprehensible code, a legitimate seeming README.MD, and a reasonable amount of downloads, it is likely to get installed.”
