Release Swap: OVHcloud CLI Backdoor

title: "Release Swap: OVHcloud CLI Backdoor" slug: "2026-10-28-release-swap-the-ovhcloud-cli-backdoor" meta_title: "OVHcloud CLI Backdoor: Release Swap Facts" meta_description: "The ovhcloud cli backdoor rode five swapped GitHub releases for 94 minutes on 19 October. Versions, clean pins, GlassWorm signals and the immutability fix." primary_keyword: ovhcloud cli backdoor author: Krova Cloud Engineering date: 2026-10-28 schema: BlogPosting+FAQPage category: AI Code Sandboxing secondary_keywords: github release immutability, supply chain binary swap, developer tool provenance, GlassWorm, CLI stealer excerpt: "Five CLI versions carried a stealer for 94 minutes while release immutability sat off. This checklist catches the next swap early."

Release Swap: OVHcloud CLI Backdoor

On 19 October a hijacked GitHub account swapped the published OVHcloud CLI binaries for malware. The ovhcloud cli backdoor rode versions 0.11.0 through 0.15.0 for 94 minutes, from 14:47 to 16:21. A customer report ended it. Nothing in the build pipeline was touched. That is the point.

The advisory numbers frame the exposure. About 250 downloads happened inside the window, per OVHcloud's advisory as reported by BleepingComputer. Versions 0.10.0 and the clean 0.16.0 bookend the affected range.

How the ovhcloud cli backdoor slipped past CI

The attacker never reached the source code or the pipelines. GitHub release immutability was off. One privileged account could edit release assets with no check at all, as BleepingComputer reported. Unit tests, functional tests and CVE scanning all passed because none of them ever ran.

This inverts the usual supply chain story. Coverage of npm worms like chaindrop focuses on package registries, while here the registry was GitHub Releases and the tampering happened after build, after test, after sign-off.

What the malware touched

The binary hunted secrets on disk: cloud keys, SSH keys, Docker config, Kubernetes credentials. Details come from the forensic write-up published by Forensicspot. Affected platforms were macOS on Intel and ARM, Linux on x86_64 and ARM64, and Windows x86-64.

Two installation paths stayed clean. Source builds and official Docker images were never affected. Neither pulls the edited release assets. That split is the best argument in the incident for image-based tooling distribution.

The account behind the swap had been compromised for months. OpenSourceMalware's findings, summarized in the same coverage, describe a scripted history rewrite on 5 March 2026. They also describe a hidden preinstall loader using a Solana memo dead drop, a known GlassWorm indicator.

The provenance checklist that catches a swap

First, turn on release immutability everywhere you publish. OVHcloud enabled it after the incident; enabling it before is the whole control. A swap needs a mutable release. Mutability is a setting.

Second, publish hashes and signatures outside the release page. A checksum in a commit, a signature in a separate store, or an entry in a transparency log gives installers a truth to check when the assets lie.

Third, prefer package managers and container images over release binaries for anything that runs in CI or in a sandbox. The clean paths in this incident were exactly those two, and our self-hosted CI runners guide already treats runner tooling this way.

Fourth, log downloads and match them against run telemetry during any disclosed window. 250 downloads is a small population; knowing which of them ran is the difference between an audit and a guess. Base image hygiene from sandbox base images shrinks that population further.

We checked the advisory coverage again on 28 October. The clean bookends stand: 0.10.0 and 0.16.0 remain safe pins for anyone scripting against this tool.

Verdict

We recommend treating release mutability as a security setting with an owner. Immutability on by default, hashes outside the release, image installs in automation, and a download-versus-execution audit for every disclosed window. This backdoor needed no zero-day and no pipeline access, only a setting left off and an account nobody watched for six months.

Limitations

• Download counts come from the vendor advisory; however, execution counts were never published, so true exposure stays unknown.
• The GlassWorm attribution rests on wallet and loader indicators, but researchers call them suggestive rather than conclusive.
• We tested none of the binaries ourselves and cannot verify the advisory hashes beyond publication.
• The checklist assumes you control your publishing stack; however, fork maintainers on shared hosts have fewer levers.

FAQ

Which OVHcloud CLI versions were affected?

Versions 0.11.0 through 0.15.0 during the 94-minute window on 19 October. Version 0.10.0 and the later 0.16.0 were clean, per the advisory.

Were Docker users exposed?

No. Official Docker images and source builds never pulled the edited release assets, which is why image-based installs are the recommended path in automation.

Does release immutability prevent repository compromise?

No. It stops edited releases after the fact; the hijacked account still needs detection through login alerts and audit review. Immutability limits damage, not access.