Git commit-signature malleability mints a second "Verified" GitHub commit with a different hash — defeating hash-based blocklists

Jacob Ginesin (Carnegie Mellon PhD student, Cure53 auditor) published research on 2 July, amplified by The Hacker News on 8 July, showing that Git/GitHub's "Verified" commit badge is not a unique identifier: given any signed commit, an attacker without the signing key can mint a second, distinct commit with an identical tree, identical author/date metadata, and a valid signature that still shows "Verified" — differing only in its resulting hash (The Hacker News, 2026-07-08; Ginesin, arXiv, 2026-07-02). The root cause is signature malleability, not a hash collision. A commit's SHA is computed over everything inside it, including the raw signature bytes in its header, and many signatures can be rewritten into a different-but-valid form.

Three malleation routes are demonstrated: (1) for ECDSA, the classical algebraic symmetry that turns a valid pair (r,s) into (r, n−s) using only public curve parameters, producing a second equally-valid signature over the same payload with different bytes and therefore a different commit hash; (2) for RSA and EdDSA under OpenPGP, appending an ignorable experimental subpacket in the unhashed subpacket region defined in RFC 4880 §5.2.3; (3) an analogous X.509/S-MIME path. GitHub does not normalize or canonicalize a signature before verifying it — no strict encoding enforcement on S/MIME, no stripping of the manipulable OpenPGP fields, and non-canonical ECDSA values accepted as-is (The Hacker News, 2026-07-08). A public exploitation tool implementing all three attacks, plus demo repos where the malleated commits still show "Verified", is released (Ginesin, git-chain-malleator). Ginesin reported to GNU/Git in January and GitHub in March 2026; neither had shipped a fix at publication, and no CVE is assigned. Maps to T1195.002 Compromise Software Supply Chain as a control-bypass primitive.