That green “Verified” badge on a signed Git commit? It doesn’t guarantee the commit hash is unique.
New research from Carnegie Mellon PhD student Jacob Ginesin shows that someone without the signing key can take a signed commit and produce a second commit — same files, same author, same date, still carrying a valid signature — with a completely different hash. GitHub happily stamps “Verified” on both.
The root cause is signature malleability. A commit’s hash is computed over everything inside it, including the raw bytes of the signature itself. Many digital signatures can be rewritten into a different but still-valid form. Change those bytes, and the hash changes — without touching a single line of code.
Ginesin’s paper, posted to arXiv on July 2, details three attack routes. ECDSA keys: flip the signature’s s value to n – s. Both check out. RSA and EdDSA keys: add an extra ignored field to the signature’s unhashed section. S/MIME keys: rewrite a length field in the DER structure. GitHub accepts all three.
What does this mean in practice? If you block a bad commit by its hash, an attacker can re-push the same content under a fresh, still-Verified hash your blocklist has never seen. Deduplication, provenance logs, and reproducible-build records that key on the hash all inherit the same weakness.
But here’s the important part: this doesn’t let anyone slip different code past a signature check. The files are identical. A pinned hash still fetches exactly what you expected. The problem is that the hash isn’t the one-of-a-kind identifier the software world assumes it to be.
The fix belongs on the forge side — canonicalize signatures before trusting them. Bitcoin dealt with this same ECDSA symmetry issue years ago with the “low-S” fix. This is a known lesson, reapplied. Ginesin reported the issue to GNU and Git in January and to GitHub in March. As of publication, no one has addressed it.
