OVHcloud CLI backdoored: turn on GitHub release immutability
A hijacked account swapped OVHcloud CLI GitHub releases 0.11.0–0.15.0 for secret-stealing builds. Release immutability was off. Here's the fix.
Someone hijacked a developer's GitHub account and replaced OVHcloud CLI releases v0.11.0 through v0.15.0 with builds designed to pull secrets off the disk. The CI pipeline was never touched. The attacker uploaded locally built binaries over existing releases, and nothing stopped them because GitHub's release immutability setting was off. If you publish binaries, scripts or plugins on GitHub Releases, check that box today.
What actually happened
Per BleepingComputer's report, which cites OVHcloud CEO Octave Klaba:
- Affected: v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0, on macOS, Linux and Windows. v0.10.0 and v0.16.0 are clean. Source builds and Docker images were not affected.
- Window: the bad release appeared at 14:47 on October 19, 2026 and was blocked at 16:21 after a customer reported it.
- Method: a hijacked developer account modified existing releases. Release immutability was disabled, so a privileged account could overwrite them without passing CI/CD checks.
- Payload: built to "retrieve secrets from the disk." Researchers at OpenSourceMalware tie it to the GlassWorm campaign. They also say the account was compromised for more than six months. That claim comes from one research group, so treat it as their finding.
- Response: OVHcloud turned on release immutability and considers the incident resolved. Anyone who installed a bad build should clean the machine and rotate every secret stored on it.
Why GitHub release immutability matters for your business
The usual supply-chain checklist covers CI: pinned actions, protected branches, reviewed workflows. All of that passed here. The attacker skipped the pipeline and edited the artifact your users actually download.
GitHub's docs put the fix one checkbox away:
- Per repo: Settings → Releases → Enable release immutability.
- Org-wide: Settings → Repository → General → Releases, then pick All repositories.
- Know the limit: it only applies to releases created after you turn it on. Republish your current version if you need it locked.
- On the consumer side: pin CLI versions in your installs and CI, and verify checksums from a source the attacker can't also edit.
One overwritten release reaches every machine that auto-updates. One setting stops the overwrite.
Key takeaways
- OVHcloud CLI v0.11.0–v0.15.0 GitHub releases were swapped for secret-stealing builds on October 19
- CI was clean; the attacker overwrote release assets with a hijacked account
- GitHub release immutability was off. It is a single repo or org setting, and it only covers future releases
- If you installed an affected build, clean the machine and rotate every secret on it
The artifact your customers download is part of your attack surface. We ship software with locked releases, pinned dependencies and pipelines you can audit. See how we build, or ask us to harden your release process.
Sources: BleepingComputer: OVHcloud CLI releases backdoored, GitHub Docs: Preventing changes to your releases.
- #github
- #release-immutability
- #supply-chain
- #ovhcloud
- #cli
Tommy Rush — Founder, Rush Commerce
Operator turned builder. 15+ years running operations — now shipping the systems businesses run on. More
Get The Rush Report weekly — one email, zero fluff.
Keep reading
Gheist: stolen GitHub tokens hit 850+ accounts, private repos
Wiz's Gheist report: stolen GitHub tokens planted 13,500+ secret-dumping workflow branches. Private repos weren't held. Hunt ci-sync branches, rotate, expire tokens.
Read itGemini API now stores prompts by default on new paid projects
Since October 26, new paid Gemini API projects log generateContent requests by default for 55 days. How to set store=false and keep customer data out.
Read it