OVHcloud CLI Releases Compromised by Malicious Files on GitHub

On October 19, an attacker compromised a contributor’s GitHub account to replace download archives for five releases of OVHcloud’s command-line tool. The new files contained malware intended to steal secrets stored on any machine that executed them, according to the cloud provider.

The malicious files were available on GitHub for 94 minutes, from 12:47 to 14:21 UTC, affecting users who installed or updated the OVHcloud CLI during that time. The malware was able to bypass hash checks on macOS, Linux x86_64 or arm64, and Windows x86_64 platforms.

In response, OVHcloud removed the compromised archives and released a clean version, v0.16.0, that evening. This new release is immutable, meaning its files cannot be altered. The source code and build pipeline remained intact, as the malicious build was simply a later commit uploaded to existing releases from April to September.

Details of the Compromise

In version v0.15.0, the attacker replaced six files: the macOS x86_64 and arm64 archives, the Linux x86_64 and arm64 archives, the Windows x86_64 archive, and the checksums.txt file. These changes ensured that the published hashes matched the new binaries. The same six files were also removed from versions v0.11.0 to v0.14.0, while other builds remained unaffected.

OVHcloud identified versions v0.11.0 through v0.15.0 as compromised, while v0.10.0 was deemed safe. Users who installed these versions before the attack and did not update afterward are still using the original, unaltered files.

Identifying Affected Users

Users who may have downloaded the compromised files include those who:

• Ran the official install script that downloads the latest release archive without checking a hash.
• Downloaded an archive directly from the GitHub release page of any of the five affected releases.
• Executed a CI job or build step that fetched the archive without a pinned hash.
• Used the CLI’s upgrade command from an earlier version installed without hash verification.

Conversely, users who installed via Homebrew, built from source, or pulled the Docker image were not affected. Homebrew’s cask during the attack pinned the original SHA-256 of each archive, preventing the installation of the compromised files.

How to Verify and Respond

A customer discovered the swap by extracting build information from the new v0.15.0 Linux arm64 binary. Key indicators of the malicious build included a pseudo-version string, a different recorded commit, and the presence of a specific build flag.

OVHcloud founder Octave Klaba advised affected users to change all secrets stored on their machines. The CLI stores OVHcloud API credentials in ~/.ovh.conf and reads them from environment variables. Users are urged to:

• Rotate every secret that could have been exposed.
• Remove the compromised binary and install the clean v0.16.0 version.
• Verify downloaded archives against the release using GitHub’s verification tools.

OVHcloud has not disclosed which files the compromised binary accessed or how many users downloaded it. A detailed postmortem is expected in the coming days.

How the Attack Occurred

Anyone with write access to a GitHub repository can overwrite files attached to a release. The download URL remains unchanged unless release immutability is enabled, which OVHcloud had not done. Klaba noted that the lack of this setting allowed the attacker to modify existing releases directly.

The compromised account belonged to a contributor whose work is included in OVHcloud’s documentation repository. The release workflow did not run during the attack, and initial checks found no other repositories affected. The method by which the account’s credentials were obtained remains unclear.

A customer’s CI job detected the swap when it began failing due to the SHA-256 pinning. The user reported the issue publicly, prompting OVHcloud to remove the compromised files shortly after. The clean v0.16.0 was published later that day.

Connection to Previous Malware Campaigns

OpenSourceMalware linked the compromised account to the GlassWorm malware campaign, which uses hidden code in Unicode characters. The researchers noted that the account had previously been involved in similar malicious activities, but no direct connection to the October binary has been established.

Source: The Hacker News