GitHub Verified Badge Can Appear on Multiple Hashes for Same Signed Commit

A new disclosure reveals that a GitHub “Verified” badge does not guarantee that a commit hash uniquely identifies signed content, undermining a core assumption behind hash-based security controls across the software supply chain. ‘ Jacob Ginesin demonstrates that an attacker without the signing key and without breaking SHA-2 can produce a second, byte-distinct commit with […] The post GitHub Verified Badge Can Appear on Multiple Hashes for Same Signed Commit appeared first on Cyber Security News.

A new disclosure reveals that a GitHub “Verified” badge does not guarantee that a commit hash uniquely identifies signed content, undermining a core assumption behind hash-based security controls across the software supply chain. ‘ Jacob Ginesin demonstrates that an attacker without the signing key and without breaking SHA-2 can produce a second, byte-distinct commit with an identical tree, identical metadata, a valid signature, and its own independent “Verified” badge, differing only in hash. The team coins the term “hash chain malleability” to describe how a single malleated commit cascades, changing the hashes of every dependent commit downstream. GitHub Verified Badge Can Appear on Multiple Hashes This is possible because Git’s signature bytes sit inside the hashed region of a commit object, so any byte-level change to the signature alters the commit hash while leaving the tree, parents, and message untouched. Crucially, verification only checks that some valid signature exists over the payload, not that it is the unique admissible encoding, leaving room for manipulation. The Arxiv details three distinct routes, each targeting a different signature scheme: Mathematical malleation (ECDSA): exploits the algebraic symmetry s↦n−s, flipping the signature to an equally valid one without touching the private key. Structural malleation (RSA and EdDSA): inserts a well-formed but unhashed OpenPGP subpacket (RFC 4880 §5.2.3) into the signature packet’s unprotected region, which verifiers must ignore, yet which alters the resulting hash. Encoding malleation (S/MIME): re-encodes the DER length field within the CMS envelope into an equivalent but non-canonical BER long form, thereby violating X.690 §10.1 while preserving signature validity. SchemeTechniqueLocal (git verify-commit)GitHubECDSAMathematical inversionAcceptAcceptRSAStructural subpacketAcceptAcceptEdDSAStructural subpacketAcceptAcceptS/MIMEDER length re-encodingRejectAccept Notably, GitHub’s server-side verifier accepted all three techniques, since it does not enforce DER canonicalization, does not strip unhashed OpenPGP subpackets, and accepts non-canonical ECDSA scalars. Because GitHub persists a “Verified” record keyed to the commit hash and never re-evaluates it, a malleated commit retains its Verified status even after the original signing key is rotated or revoked. This creates several downstream risks. Incident-response tooling that blocks a malicious commit by hash can be silently bypassed when an attacker re-pushes a content-identical “ghost” commit under a new, unlisted hash. Systems that pin dependencies to commit hashes, including Nixpkgs, Go modules, and GitHub Actions, assume a uniqueness that no longer holds, with Nixpkgs particularly exposed given its reliance on GPG signing paired with immutable hashes. Reproducible-build and provenance frameworks such as SLSA Source Track and Sigstore’s Gitsign treat the commit hash as an immutable trust anchor, and malleation duplicates that anchor rather than defending it, since the forged commit earns its own independent. The Jacob Ginesin complied with responsible disclosure, notifying GNU and Git in January 2026 and GitHub in March 2026, though the issue reportedly remains unaddressed as of this writing. Proposed mitigations include enforcing DER canonicalization for S/MIME envelopes, stripping unhashed OpenPGP subpackets before deriving any identity signal, and canonicalizing ECDSA signatures to low-s form, changes the paper argues must be enforced by any consumer relying on hash uniqueness rather than assumed at signing time. Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google. The post GitHub Verified Badge Can Appear on Multiple Hashes for Same Signed Commit appeared first on Cyber Security News.