- OVHcloud says a developer's stolen GitHub access was used on 19 October 2026 to replace ovhcloud-cli releases v0.11.0 to v0.15.0 with credential-stealing binaries.
- OVHcloud says the account was exposed through a malicious extension on the developer's personal MacBook, while its internal build systems were not compromised.
- OVHcloud says anyone who installed or updated the CLI in the 14:47 to 16:21 (UTC+2) window and ran it should rotate secrets. Teams should check who can publish releases.
A company can lock down its core systems and still lose control of what customers download. OVHcloud's incident on 19 October 2026 shows how. The French cloud provider says its internal build systems were not compromised. Customers still downloaded tampered software from its official GitHub page.
What happened
OVHcloud's security advisory says attackers used a developer's GitHub account. They replaced download files for ovhcloud-cli, the company's command-line tool. The first swap came at 14:47 (UTC+2) and hit one build. Within about 45 minutes, older releases back to v0.11.0 had been tampered with too.
A customer flagged suspicious activity in a GitHub issue at 15:50. OVHcloud removed all malicious files at 16:21. It then published a clean version, v0.16.0, with a signed tag.
OVHcloud says only people who downloaded the tool between 14:47 and 16:21 that day are affected. Earlier downloads are not. Dark Reading, citing the company's postmortem, reports about 250 downloads in that window.
How the attack worked
OVHcloud says the attackers did not touch its source code or build chain. They swapped the finished files that people download. Each bad file was the original tool, recompiled with hidden extra code. That code sits in a module called envchecker.
Each time the tool runs, the code makes a folder in the temporary directory. It copies files and credentials there and packs them into an archive. Then it sends the archive to an attacker-controlled server at a hard-coded IP address. The advisory warns that the attackers could change that address at any moment. The advisory calls the method rudimentary. Still, the sending relies on calls over Solana, a blockchain network.
That leftover folder gives victims a simple check. Look for a temp folder named "envchecker-" followed by random digits. Do not run the binary to test it. Instead, compare its MD5 hash, a file fingerprint, against the list OVHcloud published.
The weak link was personal, not corporate
OVHcloud traces the break-in to 20 October 2025. On that day, the developer put an extension called color-picker-universal, version 2.8.91, on a personal MacBook. OVHcloud says the extension makes calls using a Solana wallet tied to the GlassWorm threat actor. It also found a background service on the Mac that talks to an outside IP address.
The swap did not come from that MacBook. OVHcloud says the attackers used stolen keys instead. As far as it knows, the developer's OVHcloud laptop was not compromised.
Researcher Paul McCarty of OpenSourceMalware, quoted by Dark Reading, found the account had been compromised for seven months. He points to public repositories whose past commits were rewritten by a script on 5 March 2026.
The lesson here is that security is set by the most exposed access point, not the strongest system. OVHcloud is open about this. Its GitHub setup had controls, including mandatory two-factor login. Even so, it was less strict than its internal systems. Developers may join the organisation with personal accounts, "as do most of tech companies."
The company also says the repository was not set up for immutable releases. That means files could be changed after publication.
What the thief wanted
The advisory lists the material at risk. It includes AWS, Google Cloud and DigitalOcean credentials. It also lists data from AI coding tools. These are the Continue extension's database, Sourcegraph Cody histories, sessions from the Hermes agent and the Claude agent's configuration directory.
The advisory does not say what the attackers did with any stolen data. Still, this target list puts AI assistant histories beside cloud keys among the files worth taking. It shows how much one developer's laptop can hold.
What to ask your team
First, check whether anyone installed or updated ovhcloud-cli on 19 October between 14:47 and 16:21 (UTC+2) and ran it. If so, OVHcloud says to treat that computer's secrets as compromised. Rotate or disable them, and update to v0.16.0.
Second, ask who can publish releases for your public projects. Are personal accounts among them? Is publishing tied to your central identity system, as OVHcloud now plans?
Third, ask whether published releases can be changed after the fact. OVHcloud has now made releases immutable across its whole organisation.
Fourth, find out which cloud keys and AI tool histories sit in plain files on developer laptops. Then ask how fast you could replace them all.
A clean build pipeline does not protect customers when the download page is one personal laptop away.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OVHcloud.
