Can this GitHub release be swapped?

Published October 28, 2026

A checksum file on a release is not the same as swap-proof. GitHub's docs explain how to turn on immutable releases and verify assets. Incident write-ups explain what went wrong in one attack. ReleaseLock answers a narrower question: is this tool still swappable?

What "swappable" means

On GitHub, a published release can keep the same tag while someone with upload rights replaces the attached binaries, and the checksum file too. People who download later get different bytes under the same version name. Unless the release is immutable, that swap can succeed without moving the tag or touching the source code.

• Unlocked: assets can still be replaced after publish.
• Checksums only: hashes are published, but anyone who can replace the assets can also replace the checksum file.
• Signed or attested: stronger signals that the published bytes came from a known signer or build.
• Immutable: GitHub blocks changes. Per GitHub's docs, assets on an immutable release cannot be modified or deleted, and its tag cannot be moved or deleted while the release exists.

Checksum-only is not swap-proof

Teams often treat SHA256SUMS or checksums.txt as enough. That works when you pin a hash you already trust from somewhere else. It does not stop a release page swap: if an attacker replaces both the binary and the checksum file, a fresh download "verifies" against the poisoned sums.

A real example: OVHcloud CLI, October 19, 2026

According to OVHcloud's security advisory GHSA-862f-55f5-vmvw, a compromised OVHcloud GitHub developer account was used on October 19, 2026 to replace existing release assets for ovh/ovhcloud-cli versions v0.11.0 through v0.15.0 with malicious binaries. The window ran from 14:47 to 16:21 UTC+2 (12:47 to 14:21 UTC). OVHcloud says source code and the build chain were not affected, and that only users who installed the CLI during that window were exposed. It estimated about 250 downloads.

The customer report in ovh/ovhcloud-cli issue #300 shows how the swap looked from the outside. The checksums.txt files on v0.13.0, v0.14.0, and v0.15.0 were replaced along with the archives, and the v0.15.0 tag still pointed to its original commit. The reporter caught it because their CI pinned the SHA-256 of one release archive from earlier, and that pin started failing.

OVHcloud's advisory names the root cause: the repository was not configured to ensure release immutability. OVHcloud removed the malicious files, corrected that setting across its repositories, and published a clean v0.16.0 with a signed tag.

Two lessons follow. A checksum file on the same release did not help, because it was swapped too. A hash pinned from earlier did help, because it lived outside the release page.

What ReleaseLock checks

ReleaseLock is a public directory and API for CLIs, GitHub Actions, and install-from-releases tools. For each tracked repo it scores the latest release: immutable, attested, signed, checksums only, or unlocked. It also hashes release assets over time and flags drift when a previously seen asset hash or tag commit changes.

• Search the live ReleaseLock directory for a specific tool.
• Check one release: GET /v1/verify/{owner}/{repo}/{tag}
• Gate your CI: POST /v1/scan/workflows fails builds that use unlocked or unpinned Actions. See the org gate setup.

Quick answers

Sources

• OVHcloud, ovhcloud-cli security incident, October 19th, 2026 (GHSA-862f-55f5-vmvw)
• ovh/ovhcloud-cli, issue #300: release assets of v0.13.0 to v0.15.0 replaced on 2026-10-19
• GitHub Docs, Immutable releases
• GitHub Docs, Preventing changes to your releases
• GitHub Docs, Verifying the integrity of a release