OVHcloud CLI compromise: how a year-old extension booby-trapped an official tool
An official tool, downloaded from the official page of a well-known cloud provider. For about an hour and a half on October 19, that download also installed a password stealer. That’s what happened to the OVHcloud CLI command-line tool, and the root cause goes back to a simple extension installed a year earlier.
Few small businesses use the OVHcloud CLI themselves. But your web developer, your freelancer or your IT provider have very similar tools on their laptops, along with keys that open your website, your hosting and sometimes your Microsoft 365. That’s the link this story puts in the spotlight.
OVHcloud CLI: one year between infection and attack
From the rigged extension to the fix (Montreal time)
October 20, 2025
A colour-picker extension
An OVHcloud developer installs the “color-picker-universal” extension on a personal MacBook. It’s tied to the GlassWorm group and quietly steals credentials.
March 2026
Personal repositories rewritten
Several personal repositories of the same GitHub account are altered with a hidden loader. Nobody connects it to OVHcloud.
October 19, 8:47 a.m. EDT
The trap is set
Using the stolen keys, the attacker replaces the already published files of versions 0.11.0 to 0.15.0 of the command-line tool. No source code is touched.
October 19, 9:50 a.m. EDT
A customer spots the anomaly
Their system checks the fingerprint (the “hash”) of every downloaded file. It changed, so they open a public report.
October 19, 10:21 a.m. EDT
The rigged files are removed
About an hour and a half online, roughly 250 downloads according to OVHcloud.
October 19, 1:16 p.m. EDT
A clean version
Version 0.16.0 is released, with releases now locked (immutable).
The key point: the attacker didn’t need to hack OVHcloud. They used a legitimate developer’s access, stolen months earlier on a personal computer. And because the project’s GitHub releases weren’t locked, an account with the right permissions could replace an existing file without going through the automated checks.
What the stealer was looking for on disk
OVHcloud published the list of targeted files. It gives a very concrete picture of what sits on a technical person’s computer:
A single one of those keys can be enough to change your website, read your backups or create a mailbox in your company’s name. That’s why OVHcloud asks affected people to change every secret on the machine, not just the OVHcloud ones.
Are you affected by the OVHcloud CLI incident?
| Your situation | Affected? | What to do |
|---|---|---|
| Installed or updated the CLI on October 19 between 8:47 and 10:21 a.m. (EDT), then ran it | Yes, assume so | Change or disable every secret on that machine, delete the binary, install 0.16.0 |
| Downloaded a 0.11 to 0.15 version before October 19 | No | Move to 0.16.0 anyway |
| Installed from source, with “go install” or the official Docker image | No | Nothing in particular |
| You don’t know who, in-house or at your provider, uses this tool | Check | Look for a folder named “envchecker-” followed by digits in the temp folder of the machines involved: it gives the stealer away |
If someone else manages your website or servers, the question to ask is simple: “Did you install or update the OVHcloud CLI on October 19?” A clear answer within a day is a good sign.
👏 What the incident shows done right
A customer that automatically checked the fingerprint of its downloads raised the alarm within an hour, and OVHcloud published a detailed timeline and the list of targeted files the next day. That transparency is exactly what you want from your own vendors: ask them about it before an incident, not after.
Seven habits for the machines that hold your keys
The lesson goes beyond OVHcloud. Campaigns like GlassWorm have targeted code editor extensions and developer accounts since 2025, precisely because a single machine opens many doors.
To check this month
- ☐ List the people (employees, freelancers, web agency) who hold keys to your servers, hosting or Microsoft 365 on their own computer.
- ☐ Require multi-factor authentication on GitHub, at your host and on cloud consoles, and remove access for former collaborators.
- ☐ No production keys on a personal laptop: a managed, encrypted workstation with antivirus and updates.
- ☐ Limit code editor extensions to an approved list. A “colour picker” doesn’t need to read your configuration files.
- ☐ Prefer short-lived, narrowly scoped keys, and store the rest in a secrets manager rather than in text files.
- ☐ When a tool provides a fingerprint (hash) or signature, check it: that’s exactly what got this attack spotted within an hour.
- ☐ Write down where each secret is used. The day you have to change everything, you’ll know where to start.
These habits echo two other recent incidents: the stolen key at ConnectWise Cloud Backup, which opened Microsoft 365 tenants, and the 8 questions to ask your web host. The same reasoning applies to AI coding assistants, as we saw with the Aurora ransomware.
At NeoTech, our cybersecurity services start with an access inventory: who holds which key, on which device. For your servers and hosting, see our cloud services; automated 24/7 monitoring with on-call technician intervention then flags unusual sign-ins to your accounts.
Book your free cyber check
Not sure who, in-house or at your vendors, holds keys to your website, hosting or Microsoft 365? The free cyber check starts right there: we list the access, find what’s no longer needed, then hand you a clear plan.
Call us at 438-476-2322 or email info@neotechcloudsolutions.com.
Sources
- OVHcloud (GitHub): ovhcloud-cli security incident, advisory GHSA-862f-55f5-vmvw (October 20, 2026)
- GitHub ovh/ovhcloud-cli, issue #300: the customer’s report (October 19, 2026)
- BleepingComputer: OVHcloud CLI releases backdoored on GitHub to steal developer secrets (October 20, 2026)
- SecurityWeek: Hijacked Developer Account Used to Plant Stealer in OVHcloud CLI (October 21, 2026)
Photo: Nemuel Sereti, Pexels (Pexels licence).