OVHcloud’s CLI was poisoned for 94 minutes by a GitHub account stolen months earlier through a VS Code extension
On October 19, 2026, a compromised developer GitHub account replaced OVHcloud CLI binaries (v0.11.0 through v0.15.0) with a secret stealer for 94 minutes, reaching roughly 250 downloads. Turn on GitHub release immutability, sign your artifacts, and remove personal accounts from publication privileges.
October 19, 2026, 14:47. An OVHcloud developer GitHub account, compromised months earlier, starts replacing the binaries of the ovhcloud-cli releases with a secret-stealing build. October 19, 2026, 16:21. The malicious binaries are removed after 94 minutes of availability, and roughly 250 downloads. October 20, 2026. Advisory GHSA-862f-55f5-vmvw documents the incident end to end, with its MD5s, its IOCs, and its root cause. The lesson that goes beyond OVHcloud: the supply chain was breached not through a flaw in the code, but through a release-configuration mistake and a personal account compromised via a VS Code extension.
What happened, hour by hour
The advisory OVHcloud published on GitHub reconstructs the timeline. At 14:47 (UTC+2), the Darwin binary of release v0.15.0 is replaced. At 14:57, every binary of v0.15.0 is poisoned. At 15:30, the attacker walks back down the release chain, from v0.15.0 to v0.11.0. At 15:50, a customer reports suspicious activity through a GitHub issue. The investigation begins at 15:57; at 16:20, OVHcloud scans all of its GitHub repositories, and at 16:21, all malicious binaries are removed. At 18:52, the public announcement goes out on X; at 19:16, the clean, signed v0.16.0 is released to trigger update notifications.
Two numbers frame the incident: 94 minutes of malware availability, and roughly 250 downloads. A seemingly small perimeter — but the nature of the payload changes everything.
The payload: a secret stealer aimed at the entire developer environment
The replaced binaries were the original CLI recompiled with a Go module named envchecker, injected into the code and stripped. On each run, the malware creates a temporary folder envchecker-[0-9]{9-10}, copies the targeted files into it, prepares an archive, and exfiltrates it.
The list of collected resources is a precise inventory of a developer environment in 2026: the SQLite databases of VS Code, Cursor, Continue, and Sourcegraph Cody; the local OpenCode database; the Hermes agent sessions and history (~/.hermes/sessions); the Claude configuration directory; AWS, Google Cloud, and Azure credentials; Docker and Kubernetes configuration; npm configuration; SSH keys; Terraform credentials; .netrc; and the global Git configuration. In other words, enough to compromise not just the machine but every cloud service and repository that developer could reach.
The exfiltration is crude but clever: the code leans on Solana RPC calls through public endpoints (solana.drpc[.]org, api.mainnet-beta.solana[.]com…), using the wallet BHaDaVbdCYFNaKZGn7yLXFneWoJHZgLiBYkHxVrjyALF, then drops the archive at hxxps://45.32.148[.]174/upload — a URL the attacker can change at any moment.
The root cause: a VS Code extension installed in 2025, and non-immutable releases
The most instructive part is the root cause, documented without spin. The investigation traced back to a developer’s GitHub account. That account had been compromised months before the incident, on October 20, 2025, when the developer installed the color-picker-universal 2.8.91 extension on their personal MacBook. That extension is tied, through its Solana wallet BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC, to the Glassworm threat actor, already documented for stealing GitHub accounts.
A persistent Node.js service (plist) communicated with 162.33.177[.]177. In March 2026, several of the account’s personal repositories were already compromised, using the same wallet. The replacement of the OVHcloud CLI releases was not carried out from the developer’s MacBook, but using the stolen keys — a sign the attacker held durable publication credentials.
OVHcloud is blunt about the configuration flaw that made the attack possible: “the GitHub repository was not appropriately configured to ensure release immutability”. The source code and build chain were not affected — only the published artifacts were replaced. The fix was immediate: enabling release immutability across the whole organization, suspending the compromised account, reviewing write-access accounts, and publishing a v0.16.0 release with a signed tag.
What this changes for the supply chain
The incident illustrates three converging trends. First, account theft through an editor extension has become a supply-chain vector in its own right: a tool installed on a personal machine in 2025 produced a production incident in 2026. Second, release immutability is a cheap, deterministic control — its absence is what allowed already-published binaries to be rewritten. Third, the targeting of AI assistant history databases (Cursor, Continue, Cody, Hermes, Claude) shows attackers now treat a developer’s conversations with their agent as an asset worth stealing on par with their keys.
OVHcloud’s response is a model of supply-chain incident handling: fast acknowledgment, a detailed GHSA advisory with MD5s and IOCs, a list of immediate actions, and an announced improvement plan (review of build and publication pipelines, systematic signing of commits and releases, systematic immutability, and linking publication to a centralized IAM). The report from customer alink-tothepast and the analysis by Ivan Kwiatkowski / VirLabs.ai are credited.
Verdict
If you downloaded the OVHcloud CLI between 14:47 and 16:21 (UTC+2) on October 19, 2026, treat that machine’s secrets as compromised, rotate everything the stealer’s inventory covers — AWS, GCP, Azure, Docker, Kubernetes, SSH, Terraform, npm — and reinstall v0.16.0. For every organization that publishes on GitHub, apply the two controls that would have neutralized this attack right now: release immutability and artifact signing (or provenance), and remove personal accounts from publication privileges in favor of a centralized IAM. The supply chain is now decided less in the code than in repository configuration and the hygiene of personal machines.