OVHcloud CLI compromise: a pinned version can still change

Sources checked: 30 October 2026. FailSafe Research.

A familiar version number does not prove that today’s download contains yesterday’s bytes. The OVHcloud CLI incident is a concrete example of distribution integrity failing separately from source-code security.

The affected window and scope

OVHcloud’s official advisory says a compromised developer account replaced release binaries for versions 0.11.0 through 0.15.0 on 19 October between 14:47 and 16:21 UTC+2, equivalent to 12:47–14:21 UTC. It says source code and the build chain were unaffected, and identifies 0.16.0 as clean. Copies downloaded before the replacement window are outside that specific exposure. The vendor instructs people who ran an affected download to treat relevant secrets on the machine as compromised.

The advisory’s download count does not establish a victim count. Use the vendor’s artifact checks without executing a suspicious binary, and preserve download provenance for the investigation.

Review the publication boundary

A secure build is valuable only if the delivered artifact can be tied back to it. Inventory who can alter an existing release, replace a checksum file or change an installer’s destination. The account that edits documentation should not casually inherit every capability needed to replace executable downloads.

Version pinning limits dependency drift. Independent artifact verification addresses a different question: whether the object fetched is the object approved. A checksum stored beside a replaceable binary needs its own trust analysis. Document where the trusted expected value comes from and who can modify it.

Developer recovery reaches beyond the tool

A cloud CLI often runs beside credentials for repositories, infrastructure and AI coding assistants. Response teams should inventory the identity material reachable from the affected workstation, not only the token used by that CLI. Revoke at each issuer, examine sessions and access history, and recover the endpoint through the incident team’s trusted process.

For a controlled exercise, test whether a publishing identity can overwrite an approved artifact and whether the consumer rejects an unapproved replacement. Keep the exercise in a dedicated repository and test environment. Record which enforcement point produced the rejection.

Ask FailSafe to test delivery, not just code

An agreed application and infrastructure assessment can include artifact publishing roles, administrative paths and the credentials connecting them. FailSafe SWARM follows reachable attack paths and produces evidence for engineering handoff. Pair that work with build provenance and endpoint controls; neither a source scan nor an assessment alone proves every future download will be safe.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.