French cloud provider OVHcloud disclosed that an attacker used the GitHub account of one of its developers to plant a secret-stealing binary in its official command-line interface (CLI). According to the writeup, the attacker used a hijacked contributor account to swap out binaries on five already-published releases, and the replacement builds were designed to steal secrets from any machine that ran them. The guidance to users is direct: rotate secrets and upgrade to the fixed version.
Read that carefully, because the mechanism is more dangerous than a typical CVE. The attacker did not break into a running system. They compromised the release pipeline — the trusted path by which software gets from a developer’s hands to yours — and let everyone who installed or updated the CLI run the malicious code for them. Every user who trusted “this is the official OVHcloud CLI, from the official GitHub releases” became a victim through a channel they were right to trust yesterday.
This post is about release-hijack supply-chain attacks: how they work, why altering already-published releases is especially nasty, and the concrete defenses on both ends — for the maintainers who publish software and the teams who consume it. This is a solvable problem with controls you can adopt deliberately.
What Happened
Modern software distribution runs on trust in the publishing channel. You trust that the binary attached to a GitHub release is the one the maintainer built, that it matches the source, and that it has not been tampered with since. That trust is what lets brew install, npm install, pip install, and “download the release binary” work at all. Supply-chain attacks target exactly that trust.
Here is the OVHcloud chain, step by step:
1. A developer’s GitHub account was hijacked. The attacker gained control of a contributor account with permission to manage releases. The reporting points to account compromise — the kind that comes from phishing, credential reuse, a stolen token, or an infostealer on the developer’s own machine. Once you hold a trusted contributor’s account, you hold their permissions.
2. The attacker replaced binaries on already-published releases. This is the part that makes the attack especially effective. Rather than cutting a new, suspicious release, the attacker swapped the binary assets attached to five existing releases that users already trusted. A release tagged weeks ago, that people had already vetted and were installing by habit, silently started serving malicious code.
3. The replacement binaries were secret-stealers. When a user downloaded and ran the tampered CLI, it harvested secrets from their machine — cloud credentials, API tokens, and the other material a cloud CLI user is likely to have sitting in their environment. A cloud provider’s CLI is, almost by definition, run by people who hold cloud credentials, so the target selection is grimly efficient.
4. Every install or update propagated the compromise. No further action from the attacker was needed. The distribution system did the work: anyone who installed one of the affected versions, or whose automation pulled it, ran the stealer. CI runners and automation that fetch the CLI are especially exposed, because they often run with powerful credentials and no human watching.
Why Altering a Published Release Is So Dangerous
It is worth isolating why re-writing existing releases is worse than publishing a new malicious one, because it defeats several defenses people assume they have.
It bypasses “wait and see.” Cautious teams often avoid brand-new releases, letting others find problems first. A release that has been out for weeks has, in effect, already passed that waiting period. Tampering with it weaponizes the very caution that was supposed to protect you.
It defeats version pinning — partially. Pinning to a specific version tag protects you from a new bad version. It does not protect you if the artifact behind that version tag is swapped out, unless you are also verifying the artifact’s hash. Mutable release assets are the gap.
It poisons the trusted, boring path. Nobody re-scrutinizes a version they installed last month. Automation pulls it on a schedule. The attack hides in the part of the process everyone has stopped looking at precisely because it had been reliable.
It widens the blast radius backward in time. By altering five historical releases, the attacker potentially reaches not just future installers but anyone re-pulling, re-building, or re-provisioning from those versions — a much larger population than a single new release would hit.
The lesson: the integrity of a release is not established once at publish time. It has to be verifiable continuously, by both the publisher and the consumer, because “already published and trusted” is exactly the state attackers want to exploit.
For Consumers: Defending When You Install Other People’s Software
If you use the OVHcloud CLI — or any third-party CLI, package, or binary — here is what directly addresses this pattern.
1. Rotate secrets if you ran an affected version
If you installed or updated an affected release, assume the secrets reachable from that machine are compromised and rotate them: cloud credentials, API tokens, SSH keys, anything in the environment. This includes CI runners that pulled the CLI. Rotate first, investigate second.
2. Upgrade to the fixed version and verify it
Move to the known-good release (the fixed version called out in the advisory) and, where the project publishes them, verify checksums or signatures against the maintainer’s published values rather than trusting the download blindly.
3. Pin to hashes, not just version tags
Pinning a version number is not enough when release assets can be swapped. Where your tooling supports it, pin to a content hash (a specific artifact digest) so a silently-replaced binary fails verification instead of installing. This is the single change that most directly defeats the “altered published release” trick.
4. Treat CLIs and automation tools as privileged software
A cloud CLI runs with your cloud credentials. Treat installing or updating one with the same care as any privileged change: know what you are installing, from where, at what version, and verified how. For the broader framing of this risk, see what is software supply-chain security.
5. Limit what a developer tool can steal
The stealer’s payoff is whatever secrets sit on the machine that runs it. If those are short-lived, scoped credentials rather than long-lived keys, the payoff shrinks dramatically — a theme we will come back to, and the same reasoning behind why AI coding agents become an identity and credential risk.
For Maintainers: Defending When You Publish Software
If your team publishes CLIs, SDKs, packages, or binaries, the OVHcloud incident is a checklist for your own release pipeline.
1. Lock down who can publish releases
Publishing is one of the most sensitive permissions in your organization. Enforce phishing-resistant MFA on every account that can manage releases, minimize how many accounts hold that permission, and review it regularly. The attack started with a single hijacked contributor account — that account should have been the hardest thing to abuse, not the easiest.
2. Make release artifacts immutable
Configure your release process so that once a release’s assets are published, they cannot be silently replaced. If the platform allows mutable release assets, add your own controls — signed, immutable artifact storage and a published manifest of hashes — so a swap is detectable.
3. Sign everything and publish the signatures
Sign release artifacts and publish the signatures and checksums through a channel attackers would also have to compromise. Signing turns “trust the download” into “verify the download,” and it gives consumers a way to catch tampering you might miss.
4. Build and release from a hardened pipeline, not a laptop
Releases that are cut from an individual developer’s machine inherit that machine’s compromise risk. Build and publish from a controlled, auditable pipeline with its own hardened identity, so a stolen personal account cannot directly rewrite production artifacts.
5. Govern the pipeline’s own credentials
Your release pipeline holds signing keys and publishing tokens — the exact secrets an attacker wants. Scope them narrowly, keep them short-lived where possible, and never leave a durable publishing key sitting where a single account compromise exposes it. This is the same lesson as governing non-human identities with JIT and governing CI/CD pipeline credentials without standing secrets.
The Structural Thread: Standing Secrets and Unwatched Trust
Step back and the OVHcloud incident shares a spine with the other supply-chain stories of the moment: a trusted identity was compromised, and it held standing, long-lived secrets with enough reach to do real damage. The stealer’s whole business model depends on finding durable credentials on the machines that run it. The release-hijack’s whole business model depends on a publishing credential that stays valid and powerful.
Remove the standing secrets and both attacks lose most of their payoff. On the consumer side, if the developers and CI runners that install tools hold short-lived, scoped credentials rather than long-lived keys, a stealer that lands on the machine grabs tokens that are expiring or narrow — a fraction of the prize. On the maintainer side, if the release pipeline’s signing and publishing credentials are scoped and short-lived rather than durable and broad, a hijacked account inherits far less.
This is where correlated code-to-cloud security helps you see the exposure before it is abused. Cloudanix Code Security brings secret detection and static analysis into the development workflow, so durable credentials sitting in repositories, build configs, and developer environments are surfaced rather than discovered during an incident. Because findings are correlated across code and cloud on one asset graph, you can see which of those credentials actually reach production resources — the blast-radius picture that tells you which secret to eliminate first. And for the credentials themselves, Cloud JIT, Database JIT, and short-lived access for non-human identities replace the standing keys that make a stealer or a hijacked pipeline worth the attacker’s effort — all reporting into the broader CNAPP+ platform so code, identity, and cloud posture are one connected view.
Being Honest About What This Covers
We would rather you deploy this understanding the boundary.
What these defenses genuinely change: the integrity verification and the blast radius. Signing, immutable artifacts, and hash-pinning let a tampered release be caught instead of silently run. Scoped, short-lived credentials shrink what a stealer or a hijacked publishing account can actually take. Correlation shows you which durable secrets lead somewhere dangerous so you remove them first.
What still needs the fundamentals: account security is the root cause here, and nothing above removes the need for phishing-resistant MFA, careful management of publishing permissions, and keeping developer machines clean. A hijacked account is still the attacker’s first move; these controls make that move pay off far less. Think of account hardening as reducing how often a trusted account is taken, and the rest as containing the damage when one is.
Being precise about this is deliberate. We are not promising that no developer account will ever be hijacked. We are describing how to make a hijacked account unable to silently poison your software or drain your cloud.
Key Takeaways
- The release pipeline is the weak link. The attacker did not exploit a running system; they abused the trusted path software travels to reach you.
- Altering a published release is especially dangerous. It defeats “wait and see,” partially defeats version pinning, and hides in the path nobody re-scrutinizes.
- Consumers: rotate, upgrade, and pin to hashes. A content-hash pin is what catches a silently-swapped binary that a version tag would not.
- Maintainers: lock down publishing, sign artifacts, and release from a hardened pipeline. The hijacked contributor account should be the hardest thing to abuse, not the easiest.
- Standing secrets are the shared root cause. Short-lived, scoped credentials shrink the payoff for both the stealer and the hijacked pipeline.
Want to see which durable credentials in your repositories and pipelines can reach production — and remove the standing secrets that make a supply-chain compromise worth it? Book a demo to see Cloudanix code-to-cloud correlation and JIT on your own environment.
People Also Read
- GhostAction: Malicious GitHub Actions Workflows Hit 30,000 Repos. Your CI/CD Is an Identity Problem
- Governing CI/CD Pipeline Credentials Without Standing Secrets
- Hackers Are Scanning for Exposed Vite Dev Servers to Steal AWS and Azure Secrets
- Why AI Coding Agents Become an Identity and Credential Risk
- What is Software Supply-Chain Security?
- What is Code Security?
- Cloudanix: Code Security
