New research shows that a signed Git commit’s hash is not the one-of-a-kind name that much of the software world assumes it to be. Given any signed commit, someone without the signing key can mint a second commit with the same files, author, and date, and a valid signature, GitHub still stamps “Verified.”
Everything a reviewer would check matches. The commit’s hash does not. That matters because so many systems treat a verified commit hash as a permanent, unique name for its contents.
Here is the concrete failure: block a bad commit by its hash, and 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 inherit the same soft spot.
A compromised or hostile mirror can hand cloners validly signed commits whose hashes differ from those on the canonical forge.
What this is not is a way to slip different code past a signature check. The files are identical in every copy, so a hash you pinned still fetches exactly the content you expected, or fails.
There is no CVE and no vendor advisory, and nothing to change in your own repo: the flaw is in how a forge decides what “Verified” means, and the fix belongs on the forge’s side.
The work comes from Jacob Ginesin, a PhD student at Carnegie Mellon University and a cryptographic auditor at Cure53. His five-page paper, posted to arXiv on July 2, comes with a public tool that runs all three attacks, plus two demo repositories where the malleated commits still show “Verified” on GitHub.
Because every commit names its parent by hash, malleating one commit forces new hashes on the commits above it. The tool rewrites that chain to keep it consistent. A signed descendant, though, loses its own badge the moment its parent pointer changes. Ginesin calls the effect “hash chain malleability.”
The cause is signature malleability. A commit’s hash is computed over everything inside it, including the raw bytes of the signature in its header. Many signatures can be rewritten into a different but still-valid form, and changing those bytes changes the hash without touching a line of code.
The three routes cover every GPG scheme GitHub verifies, plus S/MIME:
- ECDSA keys: flip the signature with a classic piece of elliptic-curve algebra (turn the value s into n – s). Both forms are valid. This passes a local git verify-commit and earns a GitHub badge.
- RSA and EdDSA keys:Â add an extra, ignored field to the signature’s “unhashed” section, the part the signature deliberately does not cover. The signature still checks out, but the commit’s bytes, and its hash, change. Local and GitHub both accept it.
- S/MIME (X.509) keys: rewrite a length field in the signature’s DER structure into a longer, non-standard form. A strict local check (via gpgsm) rejects it, but GitHub still marks it “Verified,” both of which the tool reproduces.
The three routes share one enabler:…
Source link
Disclaimer
We strive to uphold the highest ethical standards in all of our reporting and coverage. We blogs.grocliq.com want to be transparent with our readers about any potential conflicts of interest that may arise in our work. It’s possible that some of the investors we feature may have connections to other businesses, including competitors or companies we write about. However, we want to assure our readers that this will not have any impact on the integrity or impartiality of our reporting. We are committed to delivering accurate, unbiased news and information to our audience, and we will continue to uphold our ethics and principles in all of our work. Thank you for your trust and support.
Website Upgradation is going on for any glitch kindly connect at [email protected]
