OVHcloud Replaces CLI After Compromised Release Archives

OVHcloud has replaced its command-line tool after an attacker used a compromised contributor GitHub account to swap download archives attached to five existing releases. The altered files were available for as long as 94 minutes on October 19, from 12:47 to 14:21 UTC, and were designed to steal secrets stored on a machine that executed them.

The affected releases are v0.11.0 through v0.15.0. The attacker replaced macOS x86_64 and arm64, Linux x86_64 and arm64, and Windows x86_64 archives, along with checksums.txt on v0.15.0. OVHcloud removed the files and issued v0.16.0 as an immutable GitHub release, preventing its assets from being modified.

Exposure depended on installation path and timing

Exposure was limited to users who installed or updated one of the affected versions during the incident window on a targeted platform. The official shell installer downloaded the latest release archive without checking a hash. The CLI upgrade command could also replace manually or script-installed macOS and Linux binaries without hash verification.

Direct downloads from GitHub release pages and automated build or CI jobs fetching an archive URL without a pinned hash were also exposed paths. An installation made before 12:47 UTC and not updated during the window retained the original file.

Homebrew users were not affected: its casks pinned the original SHA-256 values, so a substituted archive would have failed verification. Builds installed with go install, compiled from source, or obtained through the Docker image were also outside the affected paths. Linux i386, Windows i386, Windows arm64 and WebAssembly archives were not altered.

OVHcloud advises full secret rotation

OVHcloud founder Octave Klaba advised affected users to change every secret stored on disk. That includes OVHcloud API credentials held in ~/.ovh.conf or environment variables, but the scope is broader because the malicious binary may have accessed other readable secrets. OpenSourceMalware recommends performing the rotation from a different machine.

Users who ran a substituted build, or cannot determine whether they did, should remove the binary and install v0.16.0. GitHub's gh release verify-asset v0.16.0 FILE command can verify a downloaded archive against the release. Updating the CLI alone does not invalidate credentials that may already have been copied.

Release assets bypassed the build pipeline

The source repository, release tags and OVHcloud build pipeline were not changed. Instead, the attacker uploaded a plain Go build from a later commit directly to assets of releases published between April and September. GitHub permits users with repository write access to replace release files with identical names unless release immutability has been enabled.

OVHcloud said the release workflow did not run during the incident and has now enabled immutability. The company has not disclosed how the contributor account was compromised, what files the binary accessed, where any data may have been sent, or how many copies were downloaded. It has promised a detailed postmortem.

For businesses, the incident is a reason to inventory command-line tools that update from release URLs, pin and verify artifact hashes in automation, and treat release-asset permissions as production access alongside CI/CD controls.