Agent Sessions First, Cloud Keys Second: The OVHcloud CLI Release Hijack

2026-10-20 Agent & Supply Chain Security by al-ice.ai Editorial

On 20 October 2026 at 12:49 UTC, OVHcloud published GHSA-862f-55f5-vmvw, a high-severity advisory on its own ovh/ovhcloud-cli repository, describing what happened to its command-line tool the previous afternoon. A compromised developer account replaced the downloadable binaries attached to five already-published releases — v0.11.0 through v0.15.0 — with a recompiled, backdoored build. The window OVHcloud measures at 1h33, between 14:47 and 16:21 CEST on 19 October. Roughly 250 downloads landed inside it.

The advisory is unusually complete for a same-week incident writeup: full timeline, MD5s, IOCs, root cause, and a candid paragraph about why the company's GitHub presence was held to a lower standard than its internal CI. It is worth reading in full. But the detail that belongs on this site is the stealer's shopping list, because of the order it is written in.

The file list starts with the assistants

OVHcloud enumerates what the malicious binary collected. The list opens with developer-AI state and only afterwards arrives at the cloud:

VS Code and Cursor globalStorage/state.vscdb SQLite databases
The Continue extension's index.sqlite, under both VS Code and Cursor
Sourcegraph Cody chat-history.db, under both editors
OpenCode's local database (~/.local/share/opencode/opencode.db and ~/.config/opencode/opencode.db)
The Hermes agent's ~/.hermes/sessions and ~/.hermes/.hermes_history
The Claude agent's entire ~/.claude directory

Then, and only then: AWS credentials, config and CLI cache; gcloud credentials.db and access_tokens.db; the Azure profile and msal_token_cache.json; Docker config; ~/.kube/config; npm config; doctl; the whole of ~/.ssh; Terraform credentials; .netrc; and the global .gitconfig.

A credential stealer that reads ~/.aws/credentials is 2015. A credential stealer that reads a coding agent's chat history database is a different proposition, and the authors clearly thought it was the better haul. Agent session stores are not credential files, so nobody rotates them, nobody scans them, and no secret-scanning CI rule covers them — yet they contain pasted tokens, internal hostnames, architecture discussions, ticket contents and the transcript of whatever the developer was debugging that week. The same targeting shape has now appeared in the Shai-Hulud variant that went after AI coding assistants and in the OpenCode console breach. This is the third independent campaign in six months to treat agent state as a first-class exfiltration target, and the first to do it from a major cloud provider's own release page.

What the release page still shows

We checked the GitHub Releases API against the advisory rather than taking it on trust, and the asset tables corroborate it precisely. Releases v0.10.0 and v0.16.0 each carry ten assets: a checksums file plus nine platform archives. Each of the five hijacked releases — v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0 — now carries exactly four, and the same four every time: Js_wasm, Linux_i386, Windows_arm64 and Windows_i386. Every surviving asset still bears its original 2026 upload timestamp (14 April, 29 May, 25 August, 31 August, 16 September respectively), so those four were never touched.

The six names missing from each release are the five platform builds OVHcloud lists as malicious — Darwin arm64, Darwin x86_64, Linux arm64, Linux x86_64, Windows x86_64 — plus the checksums file. In other words, the attacker swapped exactly the builds people actually run and skipped the wasm, i386 and Windows-on-ARM archives entirely. The deletion OVHcloud performed at 16:21 is still legible in the asset table as a negative image of the attack.

The clean release corroborates the timeline too: v0.16.0 was published at 17:16:54 UTC on 19 October, which is 19:16 CEST, matching the advisory's entry to the minute. And the malicious build's own Go module metadata, reproduced in the advisory, reads v0.15.1-0.20261013083505-5ead8ef9b43d+dirty with vcs.revision 5ead8ef9b43d — a real commit in the repository, the 13 October merge of PR #296. The attacker compiled from genuine upstream source, marked dirty, with the stealer bolted on as an envchecker module. Source code and build chain were not touched; only the artefacts were.

A year of dwell time, and one missing checkbox

OVHcloud's root-cause section is the part defenders should sit with. The developer account was compromised when the developer installed the VS Code extension color-picker-universal 2.8.91 on their personal MacBook on 20 October 2025. The extension made Solana RPC calls using wallet BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC, attributed to the Glassworm actor, and registered a persistent NodeJS plist service talking to 162.33.177[.]177. Several of the same account's personal repositories were compromised in March 2026 with that wallet. The release swap itself was not performed from that MacBook — it was done with stolen keys.

So: infection 20 October 2025, exploitation 19 October 2026. Three hundred and sixty-four days of dwell time between a marketplace extension and a cloud provider's release page. We have covered Glassworm's colour-theme loaders on the VS Code Marketplace and Open VSX and the developer-targeting botnet takedown; this is what the long tail of that campaign buys an operator a year later. The malicious CLI's own exfiltration reuses the family's signature trick, resolving its drop point through public Solana RPC endpoints under wallet BHaDaVbdCYFNaKZGn7yLXFneWoJHZgLiBYkHxVrjyALF before uploading the archive to hxxps://45.32.148[.]174/upload.

And the control that would have stopped it is one setting. OVHcloud states it plainly: “The main issue was that the GitHub repository was not appropriately configured to ensure release immutability.” Immutable releases have since been enabled across the whole organisation, the compromised account suspended, every repository's logs reviewed, and v0.16.0 shipped with a signed tag. The company is candid that its GitHub org ran looser than its internal, audited CI because developers are allowed to attach personal GitHub accounts — “as do most of tech companies,” the advisory notes, correctly.

Checking whether you are affected

The exposure test is narrow and mechanical. If you downloaded or updated ovhcloud-cli between 14:47 and 16:21 CEST on 19 October 2026 and ran it, treat every secret on that machine as compromised — including, per the list above, anything that passed through an agent session on that host. Downloads of v0.11.0–v0.15.0 before that date are unaffected; <= v0.10.0 and >= v0.16.0 are unaffected.

Two local artefacts settle the question without executing anything. The advisory publishes MD5s for all five malicious binaries (6f2f086239f3d88eb2750e871901927d Darwin arm64, 347e65eb7f2d78d1c6872690272a6cc3 Darwin x86_64, 01f57206d37c28cf711677f612052913 Linux arm64, 301bff0b51980b9e76c93633e7cfd3bd Linux x86_64, 6a3cf153338c416169cda2fe704c8848 Windows x86_64) — hash your copy, do not run it. And the stealer creates a directory named envchecker- followed by nine or ten digits in the system temp folder on every run, and never cleans it up; its presence is a positive indicator, and its contents are an inventory of exactly what left.

The broader lesson is the one the asset table makes concrete. A release page is mutable storage unless you have explicitly made it otherwise, and a checksums file sitting next to the binaries it describes is not an integrity control when the same account can rewrite both. Signed tags, release immutability and published provenance are the only artefacts that survive an account compromise — everything else is the attacker's to edit. OVHcloud's own next-steps list converges on the same three items, and it took 250 downloads to get there.

Our verification was read-only. The incident narrative, timeline, malware target list, IOCs, MD5 hashes, root cause and remediation steps were read first-hand from OVHcloud's advisory GHSA-862f-55f5-vmvw on the ovh/ovhcloud-cli repository (published 20 October 2026, 12:49:39 UTC). The release asset tables, upload timestamps, v0.16.0 publication time and the existence of commit 5ead8ef9b43d were independently read from the GitHub REST API. No malicious artefact was downloaded, hashed, executed or contacted; no IOC was resolved or probed. Defanged indicators are reproduced as published. Brave Search was used for discovery only.

Sources: