The release assets of v0.13.0, v0.14.0 and v0.15.0 were replaced today (2026-10-19, ~12:47–13:12 UTC), weeks after those releases were published. We noticed because our CI pins the SHA-256 of ovhcloud-cli_Linux_arm64.tar.gz and started failing. Could you confirm whether this was intentional?
What changed (from the GitHub releases API):
The i386 / Windows arm64 / wasm assets of v0.15.0 are untouched.
v0.15.0 ovhcloud-cli_Linux_arm64.tar.gz : was 5c2beb56e6d83a4b426565a1557791ef759316abcc4effb38dd627c90aeb80e0 , now 3833daffcaaaab27e4e0e0833240ffcb1df8df648f4ec0bc4a75c176e28933cb
The new "v0.15.0" binary is not built from the v0.15.0 tag. go version -m ovhcloud on the new Linux arm64 binary:
So it is a local go build of a commit from 2026-10-13 (after the release, and including the instance API v2 migration from #292 / #293 ) with uncommitted changes . It also lacks the -X .../internal/version.Version ldflag from .goreleaser.yaml , so it did not come from the release pipeline. The v0.15.0 tag itself still points to 760fd72d , and the Go module proxy serves that same commit.
HassenBF is not a public member of the ovh org and doesn't show up among the repo's contributors. That may just be a private membership, but together with the dirty build it seemed worth flagging rather than assuming.
If this was a legitimate rebuild, it would help to know why, and to have release assets treated as immutable (or new versions published instead). If it wasn't, the affected assets should probably be pulled.
We have switched to building from the module proxy in the meantime. There was no private vulnerability reporting channel enabled on this repo, hence a public issue. Happy to move it elsewhere if you prefer.
FrostByte0x assigned FrostByte0x and rbeuque74 on Oct 19, 2026
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
