Overview
A compromised contributor account was used to hijack five existing OVHcloud CLI releases, replacing legitimate download archives with malicious builds designed to steal secrets from machines running the software. The compromised releases were available for approximately 94 minutes on 19 October 2026, affecting specific macOS, Linux and Windows builds. The incident is significant because the attacker did not need to compromise OVHcloud’s source repository or build pipeline. Instead, they modified the published release artefacts. That distinction exposes an often-overlooked part of the software supply chain: the code may be trustworthy while the binary being downloaded is not.
The Release Itself Became the Attack Surface
The attacker gained control of a contributor’s GitHub account and used its permissions to replace files attached to existing releases from v0.11.0 through v0.15.0. The malicious archives were designed to steal secrets stored on the systems where the CLI was executed. Because the files retained the expected release names and download paths, an organisation downloading an affected release could believe it was receiving the same software that had originally been published. Even the checksums.txt file was replaced for the affected release, meaning a verification process that trusted the compromised checksum file could also validate the malicious binaries. This is a critical supply-chain lesson: Integrity verification is only effective when the integrity reference itself is trusted.
Hash Pinning Made the Difference
Not every installation path was vulnerable. The Homebrew distribution mechanism had pinned the expected SHA-256 hashes for the original archives. When the release files were replaced, the hashes no longer matched and Homebrew refused to install the modified files. Similarly, organisations that built the CLI from source or used go install were not exposed through the compromised release archives. This demonstrates the value of independent integrity verification. A software installation process that simply downloads “the latest release” trusts the distribution channel. A process that expects a specific version and independently verifies its cryptographic identity creates another security boundary.
The CI/CD Pipeline Was Not Compromised
One of the more interesting aspects of this incident is that OVHcloud’s source code, release tag and build pipeline were reportedly not modified. The malicious files were instead uploaded directly onto existing GitHub releases. The attacker was able to do this because release immutability had not been enabled. Existing release assets could therefore be deleted and replaced while retaining the same release and download references. This created a gap between the software development pipeline and the software distribution pipeline. The build system could remain clean while customers received compromised binaries. That means securing CI/CD alone is not enough. The entire path from source code to customer download needs integrity controls.
Why the 94-Minute Window Still Matters
The malicious files were available for less than two hours, but that does not make the incident insignificant. A software supply-chain attack does not require a long exposure period if automated systems are continuously downloading and executing software. CI/CD pipelines, deployment systems, developer workstations and cloud administration environments can all consume command-line tools automatically. A compromised administrative CLI is particularly sensitive because the machine executing it may already contain cloud credentials, SSH keys, API tokens and other secrets. In this case, OVHcloud advised affected users to assume that every secret accessible from a machine that executed a compromised build may have been exposed. Replacing the binary therefore addresses the malware, but it does not revoke credentials that may already have been copied.
Immutability Should Be a Security Control
OVHcloud has since enabled GitHub’s release immutability mechanism and published a clean v0.16.0 release. The new release is immutable and includes release attestation, providing stronger assurance that the published files correspond to the intended release. The incident demonstrates why immutable releases should not be treated merely as a release-management convenience. They are a security control. If an attacker can alter a published binary without changing its version, download location or apparent release identity, downstream systems may have no obvious indication that something changed. Once release assets become immutable, that attack path becomes significantly harder to exploit.
The Developer’s Machine Is Part of the Supply Chain
The most important architectural consideration is what happens after the software reaches the endpoint. A developer workstation may contain access to source repositories, package registries, cloud platforms, Kubernetes clusters, SSH infrastructure and production credentials. A cloud CLI therefore represents more than another executable. It can act as an identity-bearing administrative tool. Compromising that tool can turn the developer or administrator’s workstation into a credential collection point, potentially allowing attackers to move into environments that were never directly compromised. This is why software supply-chain security must consider not only whether software is authentic, but what privileges and secrets are available when that software executes.
Expert in the Cloud Insight
The OVHcloud incident demonstrates a subtle but important supply-chain principle:
The software distribution channel is part of the security boundary. A clean source repository does not guarantee a clean binary. A secure CI/CD pipeline does not guarantee an unmodified release. A valid filename does not guarantee authentic contents. Organisations should therefore combine immutable releases, independent hash verification, signed or attested artefacts, version pinning and controlled software distribution wherever practical. And when a potentially compromised administrative tool has executed, replacing the tool is only the first step. The binary can be removed. The credentials it already stole must be revoked. The real objective of software integrity is not simply proving that a file is what it claims to be. It is ensuring that trusted software remains trusted from source, through build and release, all the way to execution.
Leave a Reply