A 'Verified' badge on a GitHub commit doesn't mean what you think

The green Verified badge next to a GitHub commit is supposed to mean one thing: this exact commit was signed by a key belonging to the person named on it. New research shows the badge is weaker than that. Given any signed commit, an attacker who does not have the signing key can produce a second, different commit, with a different hash but the identical content and a valid signature that GitHub still marks Verified. The trust people place in that badge, and in the commit hash under it, does not hold up the way most of us assumed.

What the researcher actually did

Jacob Ginesin, a PhD student at Carnegie Mellon University and a cryptographic auditor at Cure53, posted a five-page paper to arXiv on July 2, 2026, titled "Git Hash Chain Malleability." It comes with a public tool that runs the attack and two live demo repositories where the tampered commits still show Verified on GitHub today. The core result: take any signed commit, and without the author's private key you can generate a distinct commit that keeps the same tree, the same metadata, and a signature GitHub accepts. Only the commit hash changes.

That last detail is the sharp one. Every git commit names its parent by hash, so changing one commit's hash cascades down everything built on top of it. Ginesin calls this hash chain malleability: not one forged commit in isolation, but a whole rewritten chain that still verifies clean.

It is not a broken hash function

The paper shows three ways to do this, covering every signature scheme GitHub verifies. For ECDSA, a classic algebraic symmetry turns a valid signature pair (r, s) into the equally valid (r, n minus s). For RSA and EdDSA, you append well-formed but ignored data to the unhashed region of an OpenPGP signature. For S/MIME, you re-encode the message's length fields into a non-canonical but still legal format. Different bytes, different hash, same green badge each time.

Why the badge matters less than people assume

A lot of supply-chain security quietly rests on the belief that a commit hash is a unique, verified fingerprint. CI/CD pipelines pin builds to a specific commit hash. Dependency lockfiles record exact hashes. Incident response after a breach traces exactly which commit introduced what. All of that assumes one verified commit equals one hash equals one immutable thing. This research says one logical commit can wear many hashes, each stamped Verified, so the badge confirms a valid signature exists, not that the specific commit in front of you is the only one the author ever vouched for.

Where this stands

Ginesin disclosed the issue to GNU and the Git project in January 2026 and to GitHub in March. As of the paper's publication, neither Git nor any hosting forge had shipped a fix, and the demo commits still verify. The practical exposure is narrower than the headline sounds: this is not remote code execution, and it does not let an attacker sign as you from scratch. It weakens a specific assumption, that Verified plus a hash uniquely identifies a commit, that a surprising amount of tooling depends on.

Why a build studio cares

We live in git and GitHub all day: our own site, client repositories, and CI/CD that pins and deploys off specific commits. This is a direct reminder that a Verified badge is a signal, not a proof of uniqueness, and that supply-chain trust should rest on things that actually hold: pinning dependencies by content hash you control, verifying build provenance rather than eyeballing a badge, and not treating a commit hash as a tamper-proof unique ID in security-critical automation. We already made this argument about a different GitHub trust boundary in our writeup of the GitLost AI-agent leak; this is the same lesson from the cryptography side.

Next step: read the arXiv paper for the full method, The Hacker News' report for the disclosure timeline, and the International Cyber Digest writeup that surfaced it. If you want a second look at where your build pipeline trusts a badge instead of a guarantee, write to us at hello@gattyworks.com.