GitHub Verified Badge Is Malleable: Identical Code, Multiple Valid Commit Hashes

Vulnerability Overview

Jacob Ginesin, a PhD student at Carnegie Mellon University and a Cure53 security auditor, published a paper on arXiv (2607.02820, 2 July 2026) describing a flaw in GitHub’s “Verified” badge. The badge guarantees that a commit is signed by a trusted author, but GitHub does not treat the commit hash as a unique fingerprint. An attacker can modify the signed bytes while keeping the signature valid, producing a new commit that still shows the green Verified badge.

Technical Analysis

Three signature‑malleation paths

ECDSA signature – algebraic transformation (s → n‑s) : ECDSA signatures consist of an (r, s) pair. Replacing s with n‑s (where n is the group order) yields a still‑valid signature. The altered commit passes both local git verify-commit checks and GitHub’s server‑side verification, retaining the Verified badge.

RSA and EdDSA signatures – OpenPGP sub‑packet injection : Extra OpenPGP sub‑packets are inserted into the “unhashed” region of the signature (RFC 4880 5.2.3). Verification succeeds, but the commit bytes change, causing a new hash that GitHub still records as Verified.

S/MIME (X.509) signature – non‑canonical DER length encoding : The length field in the DER‑encoded CMS envelope is rewritten to a longer, equivalent non‑standard form. Strict local gpgsm verification rejects it, yet GitHub records the commit as Verified.

Root cause: GitHub does not normalise signatures

GitHub accepts any syntactically valid signature representation without normalising the byte sequence. It records the Verified status per commit hash without cross‑checking or deduplication, allowing a malleated commit to be treated as a distinct, yet still Verified, entity.

Hash‑chain cascading effect

Each commit points to its parent’s hash. Because the malleated commit’s parent pointer changes, the hashes of all descendant commits are recomputed, even though the underlying file contents are unchanged. The tool automatically rewrites the entire chain and pushes the new branch tip.

Impact Scope

Systems that rely on the commit hash as a unique content identifier are directly affected:

Nixpkgs : uses commit hashes for package deduplication.

Go modules : go.sum and dependency pinning trust the hash as immutable.

GitHub Actions : workflows pin a specific commit to fetch a version.

Docker/OCI references : image layers reference commit hashes.

Reproducible builds : build records use the hash as the primary address.

Vendor security blocklists : blocklists filter malicious code by commit hash.

Attack scenario example : a security team blocks a malicious commit hash. An attacker uses the malleability tool to create a new, still‑Verified commit with identical code, bypassing the blocklist.

Note : the attack does not inject malicious code—the signature still binds to the original author and the file contents remain unchanged. The trust model that treats the commit hash as an immutable identifier is broken.

Fix Status

No CVE identifier assigned.

No official GitHub fix announced.

No vendor security advisory released.

Temporary Mitigations

Overlay a content hash (tree object hash or file‑level hash) on top of the commit hash for deduplication.

Downstream systems should not treat the commit hash as the sole trust anchor after signature verification.

Include commit‑content consistency checks in CI/CD pipelines.

For S/MIME users, enforce strict gpgsm verification to block DER re‑encoding attacks (though it cannot stop ECDSA algebraic transformation).

Conclusion

GitHub’s “Verified” badge does not guarantee uniqueness. Signature malleability enables multiple valid Verified commits for the same code base, breaking the assumption that a commit hash is an immutable identifier. In an era of increasing supply‑chain security concerns, any system that depends on commit hashes as immutable keys must reassess its trust model.

Paper: https://arxiv.org/abs/2607.02820

Proof‑of‑Concept tool: https://github.com/JakeGinesin/git-chain-malleator