What changed

The release page was no longer a reliable record

A user noticed that checksums pinned by their CI pipeline no longer matched the OVHcloud CLI binaries on GitHub. Their 19 October report documented replacement assets on releases v0.13.0 through v0.15.0, including a checksums file. One replacement binary identified itself as a locally modified build of a later commit rather than a build of the release tag. The tag and Go module source still pointed to the original code.

OVHcloud maintainers said the involved binaries were removed on 19 October and then published v0.16.0 with an immutable release and signed tag. A fuller postmortem was still pending when this note was prepared. Reporting based on company statements describes the altered binaries as designed to retrieve local secrets; the public repository discussion firmly establishes asset tampering, but does not by itself establish what ran on each downloader's machine.

Keep the attribution narrow

Some reporting links this incident to a wider campaign. The available public evidence does not make that attribution a settled finding, so the response should begin with exposure and execution rather than a campaign name.

Defender workflow

A download list is more useful than a version list

  1. 1

    Find the acquisition path. Review developer workstations, CI jobs and installation scripts for OVHcloud CLI downloads on 19 October. Record the source URL, time and preserved binary hash where available; do not assume an old version number means an old, clean asset.

  2. 2

    Determine what executed. Separate downloaded-but-unused files from binaries actually run. For executed replacements, identify accessible cloud credentials, API tokens, SSH material and other secrets, then scope and rotate them through an incident-response plan.

  3. 3

    Reinstall from a trustworthy release. Remove suspect binaries and obtain a clean build using OVHcloud's current guidance. Verify the new artifact and track the vendor's postmortem for a final exposure window and additional indicators.

Defender note

Source integrity and release integrity are different controls

This case illustrates why reviewing a Git tag is not enough when users install prebuilt release files. A release asset can change while the source tree remains intact. Immutable releases, independent checksums or attestations, and pinned artifact hashes make that gap easier to detect; the user who spotted it did so because CI expected a specific hash.