OVHcloud CLI Compromised: GitHub Release Binaries v0.11.0 to v0.15.0 Swapped for an Infostealer

Attackers replaced the release binaries of OVHcloud's open-source command-line tool, ovhcloud-cli, with an infostealer on October 19, 2026. They did it through a hijacked OVHcloud developer's GitHub account, and the malicious files were downloadable for about 94 minutes before OVHcloud removed them. This is a compromise of a developer tool's download channel. It is not a backdoor in OVHcloud's hosting platform, its servers or its customers' services.

The affected releases are v0.11.0 through v0.15.0. If you installed or updated ovhcloud-cli in that window and ran it, the binary was built to collect secrets from your disk. This post covers the mechanism, who is affected, how to check without running anything, and what to rotate. It also covers why this matters if an AI coding agent or a CI job installs CLIs for you. For the wider month, see our October 2026 supply-chain incidents tracker and the October 2026 attacks timeline.

TL;DR

What happened?

According to BleepingComputer and SecurityWeek, an attacker used the GitHub account of a legitimate OVHcloud developer to upload binaries over the files of five already-published releases. Only the most common platform builds were replaced. A customer reported the tampering, and OVHcloud blocked the files at 16:21 Paris time.

OVHcloud's CEO, Octave Klaba, announced the incident on X and attributed the gap to GitHub's release immutability setting not being enabled. Without it, a user with the right permissions can edit an existing release directly, with no CI/CD run in between. OVHcloud says its pipelines, including unit tests, functional tests and CVE detection, were not involved. OpenSourceMalware reports the malicious binary was built locally and uploaded through the GitHub Releases API, with no tag pushed and no workflow run.

OVHcloud has since turned release immutability on, deleted the malicious files and published a clean v0.16.0 with a signed tag.

Timeline

Sources differ slightly on the details. OpenSourceMalware puts the actual asset replacement between 12:47 and 13:12 UTC, based on one reporter's capture it says was not independently confirmed. The press reports and the advisory count the exposure window as roughly 94 minutes.

Who is affected?

You are in scope if all of these are true:

1. You installed or updated ovhcloud-cli on macOS, 64-bit Linux or Windows x86_64.
2. You used the official install.sh, Homebrew (brew install --cask ovh/tap/ovhcloud-cli) or a direct GitHub download.
3. You did it during the window on October 19.
4. You ran the binary.

You are not in scope if you built from source, used go install, or pulled the official Docker image. Per the advisory, someone who downloaded v0.11.0 to v0.15.0 before the window also holds a clean copy.

One caveat on the version range. The CEO said v0.11.0 through v0.15.0, and the advisory lists all five. Some early public coverage described only the later releases, so v0.11.0 and v0.12.0 rest on OVHcloud's statement and the advisory rather than on independent analysis. The replaced binaries were deleted before anyone archived them, so researchers did not obtain a payload sample.

How do I check if I am affected?

Do these before running the CLI again.

# Which version is installed, and where did it come from?
ovhcloud --version
which ovhcloud
brew list --cask 2>/dev/null | grep -i ovh

# When was the binary written? Compare against Oct 19, 2026.
ls -l "$(which ovhcloud)"

# Hash it without running it, then compare to the per-platform MD5s in the advisory
md5sum "$(which ovhcloud)"        # Linux
md5 "$(which ovhcloud)"           # macOS

# Look for the stealer's leftover working folder in the temp directory
ls -d "${TMPDIR:-/tmp}"/envchecker-* 2>/dev/null

Three signals matter:

• File date. A binary written on October 19 inside the window and reporting v0.11.0 to v0.15.0 is the case to worry about.
• Hash. The advisory GHSA-862f-55f5-vmvw lists MD5 hashes per platform (Darwin arm64 and x86_64, Linux arm64 and x86_64, Windows x86_64). Copy them from the advisory itself rather than from a news article. MD5 is weak for general integrity use, but here you are matching a known-bad file.
• envchecker- folder. The advisory says the stealer copies collected files into a temp folder named envchecker- followed by 9 or 10 digits and never deletes it, so its presence means the binary ran.

A missing folder is not proof of safety. Treat a matching hash or version-and-date combination as enough to act.

What did the malware target?

The advisory lists cloud credentials (AWS, Google Cloud, Azure, DigitalOcean), container and orchestration config (Docker, Kubernetes), developer files (Git, npm, Terraform, .netrc, SSH keys), and local data from editors and AI assistants, including VS Code, Cursor and Claude. Treat that list as what OVHcloud says it found, not as a complete capability list: nobody outside OVHcloud has published a full analysis of the final payload.

OpenSourceMalware's analysis of the loader found a preinstall.js stage that hides code in invisible Unicode characters and fetches its next payload location from a Solana wallet memo. The researchers did not analyze the final payload delivered through the trojanized CLI.

What to do if you ran an affected binary

The steps below follow OVHcloud's advice plus ordinary incident hygiene.

1. Stop using the machine for sensitive work until you have finished the steps below, and do not run the CLI again.
2. Delete the binary and install v0.16.0 or later from a verified source, or build from source.
3. Remove leftovers. Delete any envchecker-* folders in the temp directory after noting their timestamps. On macOS, OpenSourceMalware lists ~/init.json as a marker of an earlier-stage loader, which relates to the March loader, not necessarily this binary.
4. Rotate from a clean machine. Cloud keys (OVHcloud, AWS, GCP, Azure, DigitalOcean), SSH keys, Git and GitHub tokens, npm tokens, Docker and registry credentials, Kubernetes configs, Terraform state backends and .netrc entries. OVHcloud's CEO put it as changing all secrets on the disk.
5. Rotate AI provider keys and review agent config. If the machine ran Claude Code, Cursor or similar, API keys in env files and agent settings were in reach of a disk-reading stealer.
6. Review logs. Check cloud audit logs and Git hosting security logs from October 19 onward for logins, new keys and unexpected API calls.

The first 24 hours after a vendor breach runbook has a longer rotation order, and the Railway breach post shows how fast stolen AI keys get monetized.

Why did it take months to surface?

OpenSourceMalware says the hijacked account shows attacker-linked activity from March 5, 2026, about 228 days before the release swap, and press reports put the compromise at roughly seven months. The researchers say the same actor doing both the March and October activity is their inference. How the account was first taken over (an infostealer, a stolen token or something else) is unknown, and so is whether the account owner or the attacker made any given push in between.

Is this GlassWorm?

Possibly. Dark Reading ties the incident to GlassWorm threat actors; we could not load that article ourselves, so we cite it for the claim and rely on the other sources for detail. The basis in the OpenSourceMalware research is a Solana dead-drop wallet that appears in public GlassWorm indicator lists, plus an amend-and-force-push pattern that matches a documented campaign. OVHcloud has not used the name. Treat attribution as a researcher assessment, not a confirmed fact. It does not change what you should do.

Why this matters if an agent or CI installs your CLIs

This incident hit people who piped an install script or downloaded a release. That is exactly what coding agents and CI jobs do when a task says "set up the OVH CLI". An agent running curl ... | sh or brew install on a developer laptop will fetch whatever the release points to at that moment, and then run it with the developer's full filesystem access.

Three practical consequences:

• Pin and verify. Pin a version, and verify a checksum or signature taken from a source that is not the same release page. Here even checksums.txt was among the replaced assets, according to OpenSourceMalware, so a checksum file from the same release proves nothing.
• Do not let agents install binaries unattended on a machine that holds cloud credentials. Use a throwaway container or a profile without your ~/.aws, ~/.ssh and .netrc.
• Prefer channels that failed differently. Docker images and source builds were unaffected here; neither is a guarantee against the next incident.

The same shape appears in our coverage of fake Claude Code installers, the Aokigahara infostealer that reads agent credential stores and the LiteLLM PyPI and Docker compromise: a trusted install path is swapped, and the payload goes after developer and agent credentials.

What is known, and what is not

Not the March OVHcloud claim

Do not conflate this with a March 2026 BreachForums post that claimed a huge OVHcloud data theft. That claim was unconfirmed, and Klaba publicly said the sample was not in OVHcloud's databases. As far as we found, it has no stated connection to the CLI incident, which has a published advisory and a named mechanism. The two are separate stories.

How Beam handles this

Beam does not cover this attack directly, and we would rather say so. beam add package fetches npm packages with --ignore-scripts and runs heuristic scans before install. A Go CLI shipped as a GitHub release binary is outside that scope, and Beam does not compare binaries against published hashes. The scan is heuristic: it catches known shapes, not novel ones.

What Beam can add is on the agent side. It flags agent reads of .env and credential files on a developer machine, which helps you find where secrets live and notice an agent touching them. That is evidence for a review, not a block on a stealer that runs as its own process. Checking hashes, pinning versions and rotating credentials remain manual steps. See how to stop Claude Code running dangerous commands for the hook-based controls Beam does ship.

Related reading

• October 2026 software supply-chain incidents tracker
• October 2026 attacks timeline
• Poisoned repo hooks: testmetest armed 42 GitHub repos
• npm supply-chain worms are coming for your AI tooling
• Fake Claude Code installers target developers
• Aokigahara infostealer: Claude Code, Codex and Cursor credentials
• Your first 24 hours after a vendor breach: rotation and monitoring runbook
• API keys in logs and env vars: how they leak and how to catch it

Primary sources: OVHcloud advisory GHSA-862f-55f5-vmvw · BleepingComputer · SecurityWeek · Dark Reading · Help Net Security · OpenSourceMalware

Accurate as of October 29, 2026. The payload was never fully analyzed and the investigation may change these details; check the OVHcloud advisory for updates.