OVHcloud's CLI booby-trapped on GitHub: versions v0.11 to v0.15 hit

What happened on Monday

On Monday 19 October at 2:47 pm, someone compromised the GitHub repository of OVHcloud’s official command-line client, the tool you use to drive your accounts from a terminal. According to the host’s explanations, reported on Tuesday morning by Next, the attacker used the GitHub account of one of the company’s developers. They swapped the legitimate code for a version carrying a malicious binary, built to collect the secrets lying around on the machine’s disk: passwords and credentials. A tool meant to manage your infrastructure had decided to manage your keyring as well.

The problem was reportedly spotted and blocked at 4:21 pm. The alarm didn’t come from an internal tool but from a user. In an issue opened on GitHub, they reported that their continuous integration pipeline was failing when it checked the hash of the executable’s archive for Linux on ARM. Hardly a security operations centre, but it got the job done.

Shortly before 7 pm, Octave Klaba, CEO of OVHcloud, said the initial checks showed no other repository had been affected. He described the binary as “mediocre” in quality, yet still able to finish its job, which is about the worst combination you can get. His instruction: “If you are affected, please change all the secrets on your disk.”

Releases you could edit after the fact

Around 10:30 pm, OVHcloud published its analysis. The CI/CD pipelines were not touched, and neither were the unit and functional tests or CVE detection. The cause was a repository setting: “The problem comes from the release immutability option on GitHub, which had not been enabled.”

This GitHub option locks a release’s files once they are published. They can no longer be replaced or deleted, and any change has to go through a new version. Without it, an account with the right permissions could edit existing releases directly. And OVHcloud’s checks only run when code goes through its continuous integration and deployment pipeline. A change made directly on GitHub therefore walked straight past every one of them. Picture a state-of-the-art alarm on the front door and the back door left wide open. The option is now enabled and the company has declared the incident closed.

The affected versions

Five versions of the client were modified: v0.11.0, v0.12.0, v0.13.0, v0.14.0 and v0.15.0. The risk concerns precompiled binaries of those versions that were downloaded and then run during Monday afternoon’s exposure window. Because the attacker rewrote existing releases, sticking with an older version offered no protection: v0.11.0 was hit just as hard as v0.15.0. For once, putting off your updates bought you nothing.

A new version was published on Monday evening. Next lists it as “v.016.0”, and OVHcloud presents it as safe and, this time, immutable.

What to do if you installed it

If you installed or updated the client, then ran the binary of one of those versions on Monday between 2:47 pm and the announced block around 4:21 pm, assume every secret on the machine may have been read. Revoke them and create new ones, starting with:

• your OVHcloud credentials, especially API keys;
• your SSH keys;
• the credentials tied to your hosting;
• the secrets sitting in your environment variables.

The list is long because the binary rummaged through the whole disk, not just the client’s configuration. Also check any CI pipelines that download the tool automatically: that is exactly where the swap was caught. Installing the version released on Monday evening puts the tool right, but you can’t un-leak a secret. Once it’s out, it stays out.

On Monday, the alarm didn’t come from the vendor’s own checks. It came from a hash check one user had kept in their own pipeline. The most boring line in your CI config may turn out to be the one doing the real work.