July 7, 2026
Verified badge, unverified vibes
Git Hash Chain Malleability
Signed Git commits looked untouchable, but the comments are already fighting about whether anyone should care
TLDR: Researchers say signed Git history can be reshaped into a different-looking commit that still appears verified, which could confuse tools that trust commit IDs as fixed labels. In the comments, some called that a serious failure to act, while others basically said: calm down, this barely matters.
A fresh security paper just lobbed a grenade into one of coding’s favorite comfort blankets: the idea that a signed Git commit is a one-of-a-kind, locked-in proof of exactly what was approved. The researchers say that’s not actually true. In plain English, they claim someone can take a signed code snapshot, reshuffle parts of the packaging without changing the actual files, and end up with a different commit ID that still gets a shiny Verified badge on sites like GitHub. Same code, same signer, different label — and that can ripple through everything that depends on that label.
But if you expected instant panic, the comments had other plans. One camp went full “this is bad and nobody fixed it”, zooming in on the authors’ disclosure note and the awkward fact that they say Git and GitHub were told months ago with no real response. That alone gave the thread a strong “hello, is anyone driving this bus?” energy. The other camp was much less impressed. One commenter flatly said, “I don’t think this is really a problem,” while another challenged the paper’s premise, arguing that many tools pinned to commit IDs don’t even check signatures in the first place. And then there was the side-quest chaos: one person got hung up on why GNU was contacted at all, turning a security discussion into a mini detective story about who even owns what. Classic internet: scary claim, shrugging skeptics, and one gloriously nerdy argument about the mailing list guest list.
Key Points
- •The paper claims a signed Git commit can be transformed into a different commit with a different hash while preserving the same tree, metadata, valid signature, and GitHub verification.
- •It introduces the term "hash chain malleability" to describe how modifying one signed commit changes the hashes of all dependent descendant commits.
- •Three malleation routes are presented: ECDSA algebraic inversion, insertion of an unhashed OpenPGP subpacket for RSA and EdDSA, and non-canonical DER length re-encoding in S/MIME/CMS.
- •The article states that ECDSA inversion and OpenPGP subpacket insertion pass local `git verify-commit` checks, while all three methods produce persistent verified records on GitHub.
- •The paper says the issue affects workflows that treat commit hashes as content-addressable primary keys, including commit blocking, dependency pinning, and reproducible-build systems.