Published October 21, 2026. Based on public reports available on that date; details may change.

On October 19, 2026, an attacker used a hijacked developer GitHub account to replace the downloadable files of OVHcloud CLI versions v0.11.0 through v0.15.0 with a build that looks for secrets on the user's disk. If you or your CI pipeline downloaded the OVHcloud CLI that day, check the binary, rotate every secret that machine could read, and install v0.16.0. Websites hosted on OVHcloud were not changed by this incident, but the credentials used to manage them may have been exposed.

What happened

The OVHcloud CLI (ovhcloud, from the ovh/ovhcloud-cli GitHub repository) is a command-line tool for managing OVHcloud services. Agencies and developers use it to manage servers, domains and hosting from a laptop or a deployment pipeline.

According to OpenSourceMalware's analysis, the attacker used the account of a developer with write access to upload new files to five already-published releases. No code change or build pipeline was involved; the files were uploaded directly through GitHub's release interface. The first replaced files appeared at 12:47 UTC on October 19, a customer's CI job failed its checksum check and reported it at 13:50 UTC, and OVHcloud removed the replaced files at 14:21 UTC. The malicious files were available for about an hour and a half.

OVHcloud founder Octave Klaba said the binary was built to retrieve secrets from the disk, told affected users to change all the secrets on their disk, and said first checks found no other affected repositories. OVHcloud published a clean v0.16.0 and turned on GitHub's release immutability, which stops published release files from being changed.

Who is affected

You are at risk if you installed or upgraded the CLI on October 19, 2026 through:

  • the install.sh script,
  • Homebrew (brew install --cask ovh/tap/ovhcloud-cli or brew upgrade),
  • a direct download from GitHub Releases for v0.11.0 to v0.15.0,
  • a CI job or Dockerfile that downloads the release archive.

The replaced builds were for macOS (Intel and Apple silicon), Linux (x86_64 and arm64) and Windows x86_64. Installing with go install, building from source, and the ovhcom/ovhcloud-cli Docker image were not affected.

How to check your machine

The malicious build was compiled differently from the real releases, which makes it easy to spot:

  1. Run ovhcloud version. Clean builds print a release tag; the malicious build does not.
  2. If Go is installed, run go version -m $(which ovhcloud) and look for vcs.modified=true or a version ending in +dirty. Either one means the malicious build.
  3. On macOS, check whether a file named ~/init.json appeared in your home folder, which the researchers list as an indicator.

If any check points to the malicious build, assume it ran and stole what it could reach.

What to do now

Rotate secrets from a different, clean machine, because the affected one may still be watched. Researchers list these as exposed if the build ran:

  • OVHcloud API keys and consumer keys, and the ~/.ovh.conf file,
  • SSH keys, including keys used to reach client servers,
  • other cloud provider credentials,
  • package registry tokens and Kubernetes configs,
  • the contents of .env files, which for WordPress projects often hold database passwords and API keys.

For agencies, the WordPress part is easy to miss. If deployment credentials for client sites lived on that machine, change the hosting, SFTP and database passwords for those sites, regenerate the security keys and salts in wp-config.php, and check each site for unfamiliar admin users. Our WordPress hardening checklist covers the credential steps.

Then remove the affected binary and install v0.16.0 or later. In CI, pin release hashes and check them, the same check that caught this incident. OVHcloud signs v0.16.0 with a release attestation you can verify with gh attestation verify.

When to get help

If the malicious build ran on a machine that held client credentials, a quick review of the sites it could reach is worth the time: look for new admin users, changed files and unexpected outbound connections. Our security audit covers this across many sites at once, and if you find signs of a compromise, see how to find a backdoor in WordPress.

Sources