A saved checksum caught what an unchanged version number concealed. On October 19, files attached to older releases of the official OVHcloud command-line tool were replaced. A user’s automated build rejected a download because its SHA-256 no longer matched the value recorded earlier. OVHcloud removed the affected files and published a new release; anyone who ran an affected download needs to investigate the secrets available on that machine, as well as replace the tool. [1]
The old release suddenly contained a new build
The report began as a question in OVHcloud’s GitHub repository. Releases v0.13.0, v0.14.0 and v0.15.0 had acquired new downloadable files weeks after publication. The reporter’s Linux ARM64 archive failed the checksum pinned in their continuous integration (CI) job. The attached evidence placed the replacements between approximately 12:47 and 13:12 UTC.
Inspection of the binary’s build information found a second mismatch: the file labelled v0.15.0 came from a later commit and a working tree with uncommitted changes. Meanwhile, the original v0.15.0 source tag still pointed to its earlier commit. This was a difference between the downloadable artifact and its apparent source version. It did not require a new release name to reach users. [1]
The replacement checksum would have agreed
OpenSourceMalware’s investigation found that the replacement operation also covered checksums.txt. That makes the saved CI value the important detail: downloading an archive and its checksum together from the same compromised release page can produce a reassuring match. Comparing against a digest already held separately exposed this change.
The researchers reconstructed a release-asset attack through a contributor’s GitHub account. They found no corresponding tag push or release workflow run during the replacement window. They also said the removed binaries were unavailable for their own payload analysis. OVHcloud’s description of a program intended to retrieve local secrets should therefore be separated from claims about exactly which files it read or how many credentials were stolen; those details remain unpublished. [2]
What October 19 download records can establish
The research report, citing OVHcloud’s public warning, identifies v0.11.0 through v0.15.0 as affected release versions. A maintainer confirmed deletion of the involved binaries at 16:21 GMT+2, or 14:21 UTC. The first replacement was reported at 12:47 UTC. Treat that interval as the exposure window to investigate, rather than treating every historic installation of those versions as an infection. [1] [2]
Check download timestamps, CI logs, cached archives and installation records on developer workstations and build agents. Preserve suspect files without running them. A version string alone cannot establish when an archive was acquired or whether it was replaced. A container build that fetched a GitHub release archive also needs review: the word “container” does not tell you where its executable came from.
OpenSourceMalware distinguishes the replaced release downloads from builds obtained from unchanged source or the Go module proxy. That distinction is about the distribution route in this incident. It is a reason to examine the actual build input, not to assume every machine using OVHcloud services was exposed. [2]
A clean download does not revoke a stolen key
If an affected executable ran, removing it stops future use of that copy but cannot withdraw credentials it may already have read. Review the secrets accessible to the account that ran it, revoke or replace them from a trusted machine, and examine the associated service logs for misuse. Prioritize the workstation or build agent’s real access: a narrowly scoped deployment token and a broadly privileged administrative key create different response obligations.
Our account of an AWS key quarantined seconds after a leak explains the related problem: a provider blocking the original credential does not by itself establish that the response is complete. Host investigation and account-side recovery answer different questions.
The new release closes the artifact-replacement path
OVHcloud published v0.16.0 on October 19. Its GitHub page marks the release immutable and displays the tag signature; a maintainer identified it as the replacement release and promised a fuller post-mortem. Immutability prevents editing its attached assets in place. It does not retroactively validate an older download or prove that an exposed secret was never used. [3]
The transferable lesson is a specific trust boundary. A familiar repository, unchanged version and matching nearby checksum can all describe a file that has been substituted. The CI job caught this incident because it remembered what the download should have been. The Packagist/GitHub release-distribution case offers further context on following a package to the file it actually installs.
References
- alink-tothepast and OVHcloud maintainers. “Release assets of v0.13.0–v0.15.0 replaced on 2026-10-19 with a dirty build of a later commit.” GitHub issue #300, October 19, 2026; accessed October 20, 2026. Report and maintainer response.
- OpenSourceMalware, @6mile. “Glassworm Hacks OVH Clouds CLI tool.” Published October 19, updated October 20, 2026; accessed October 20, 2026. Release-asset investigation.
- OVHcloud. “v0.16.0.” GitHub release, October 19, 2026; accessed October 20, 2026. Immutable replacement release.
