💻 computer science

Git Hash Chain Malleability

This paper demonstrates that Git commit hashes are malleable, allowing attackers to generate distinct commits with identical content, valid signatures, and "Verified" badges by exploiting algebraic inversion in ECDSA, unhashed OpenPGP subpacket insertion, and non-canonical DER length re-encoding, thereby undermining the security assumptions of hash-based dependency pinning and reproducible builds.

Original authors: Jacob Ginesin

Published 2026-08-07

📖 6 min read🧠 Deep dive

CC BY 4.0

Original authors: Jacob Ginesin

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the internet as a massive, global library where every book, every recipe, and every instruction manual is stored in a digital vault. To keep this library organized, every single item gets a unique ID card made from a special code. In the world of software development, this system is called Git. Think of a "commit" as a snapshot of a project at a specific moment in time—like taking a photo of a Lego castle you just built. To make sure no one sneaks in and swaps a brick for a plastic one, developers can "sign" their photos with a digital seal, like a wax stamp on a letter. This seal proves, "Yes, I built this, and no one changed it."

The big idea behind this system is trust through uniqueness. If you have the photo's unique ID code, you should be able to find that exact photo and know it hasn't been altered. It's like saying, "If the ID card says 'Castle A,' then 'Castle A' is the only thing in the world that fits that description." This trust is so strong that computers use these ID codes to automatically check if software is safe, to lock in specific versions of code so they don't break, and to prove exactly who built what. If the ID code is unique and unchangeable, the whole system works like a well-oiled machine. But what happens if someone can take a perfectly good, signed photo, change the wax stamp just a tiny bit, and get a brand new ID card that still proves the photo is real? That's the question this paper asks.

The Great Digital Identity Swap

In this paper, a researcher named Jacob Ginesin discovered a sneaky trick that breaks the "one photo, one ID" rule in Git. He showed that an attacker, without needing to steal the secret signing keys or break the math behind the digital seals, can create a second, totally different ID card for the exact same piece of software.

Here is the magic trick: The attacker takes a signed commit (a photo with a wax seal) and tweaks the seal in a way that looks different to a computer but means the exact same thing to a human. It's like taking a wax seal, pressing it into a slightly different shape, or writing the same message on a piece of paper but using a different font. The content of the photo hasn't changed at all—the Lego castle is identical. The seal still proves the author's identity. But because the "look" of the seal changed, the computer generates a completely new ID card for it.

The scary part? The computer systems that check these IDs (like GitHub) say, "Hey, this seal is valid! This is a verified commit!" and give it a shiny green "Verified" badge. Now, you have two different ID cards for the exact same Lego castle. One says "Castle A," and the other says "Castle B." Both are signed by the same person, and both are marked as "Verified."

The Three Ways to Trick the System

The paper explains three different ways to pull off this trick, depending on what kind of digital seal is being used:

The Math Flip (for ECDSA): Imagine a number line where you have a number, say 5. In this specific math game, the number 5 and the number "Total minus 5" are actually the same thing. The attacker just flips the number on the seal. It looks different, but the math says it's still a valid signature.
The Hidden Note (for RSA and EdDSA): Imagine a sealed letter. The seal covers the main message, but there's a little pocket on the back that isn't sealed. The attacker slips a tiny, harmless note into that pocket. The main message is untouched, and the seal is still valid, but the letter now has a slightly different weight and shape, which changes the ID card.
The Fancy Font (for S/MIME): Imagine writing a number like "32." You can write it as "32" or as "0x20." Both mean the same thing, but one is the "standard" way and the other is a "fancy" way. The attacker rewrites the number in the fancy way. The computer that checks the letter (GitHub) is a bit lenient and accepts the fancy font, but a stricter computer (your local laptop) might get confused and say, "Wait, that's not the standard way!"

Why This Matters: The "Ghost" Problem

You might think, "So what? If the castle is the same, who cares if the ID card is different?" But in the digital world, the ID card is the castle.

The Bouncer Problem: Imagine a bouncer at a club who has a list of banned IDs. If you are banned, you can't get in. But if the attacker creates a "Ghost ID" for the same person that isn't on the banned list, the bouncer lets them in. The attacker can sneak malicious code past security filters just by changing the ID card.
The Mirror Problem: Imagine two mirrors facing each other. One shows the real castle; the other shows a "Ghost Castle" that looks identical but has a different name. If you are looking at the wrong mirror, you might think you are seeing the original, but you're actually seeing a copy that the attacker controls.
The Broken Chain: Because every new Lego castle in a chain is built on top of the previous one, changing the ID of one castle changes the ID of every castle built after it. This creates a "fork" in history. You end up with two parallel timelines: one with the original ID and one with the ghost ID. Both look real, both are signed, but they are different.

The Verdict

The paper proves that the "Verified" badge on a commit hash is not a unique guarantee of content. It's like having a "Verified" stamp on a passport that doesn't guarantee you are the only person with that face; it just guarantees the stamp is real.

The author built a tool that can automatically do this trick to any signed commit. They tested it on GitHub, and the site happily accepted the "Ghost" commits, giving them their own "Verified" badges. This means that systems relying on these ID cards to block bad actors, lock in software versions, or prove who built what are vulnerable. The fix isn't to stop signing; it's to make sure the computers checking the seals are strict enough to say, "No, that's not the exact same seal we saw before," and to check the actual content, not just the ID card.

In short: A signed commit is a promise, but the paper shows that the promise can be written in a way that creates a "ghost" version of itself, fooling the systems that are supposed to keep us safe.

Technical Summary: Git Hash Chain Malleability

Problem Statement
The paper challenges the widely held invariant in Git ecosystems that a commit hash uniquely and immutably identifies a specific piece of signed content. While Git documentation asserts that cryptographically secure hashes allow third parties to trust the hash as an address for the signed object and its references, this paper demonstrates that this assumption fails for signed commits. Specifically, an attacker without access to the private signing key, and without breaking the underlying hash function (SHA-1 or SHA-256), can generate a distinct commit object with an identical tree, metadata, and message, but a different commit hash. Crucially, this modified commit retains a valid signature and receives a "Verified" badge from Git forges like GitHub. Because the commit hash is a deterministic function of the serialized content (including the signature bytes), altering the signature bytes changes the hash. This phenomenon, termed "hash chain malleability," allows an attacker to create a "ghost" commit that is functionally identical to the original but possesses a different identifier, cascading changes to all dependent commit hashes in the chain.

Methodology
The author identifies that the gap between "a valid signature" and "this specific signature encoding" allows for malleation. They categorize three distinct techniques to exploit this gap, each targeting a different layer of the signature representation within the Git commit object:

Mathematical Malleation (ECDSA): Exploiting the algebraic symmetry of ECDSA signatures. For a signature $(r, s)$ on a curve of order $n$ , the pair $(r, n-s)$ is also a valid signature for the same message. The author modifies the $s$ value in the OpenPGP packet, re-encode the integer, and update the packet length headers. This preserves the signature's validity while altering the byte sequence.
Structural Malleation (RSA and EdDSA): Targeting the OpenPGP container structure rather than the signature value itself. The author appends a well-formed, non-critical subpacket (type 100, private/experimental) to the unhashed region of the signature packet. Per RFC 4880, the unhashed region is not covered by the cryptographic signature. By adding data here and adjusting the packet length, the signature remains valid, but the commit object's byte representation changes.
Encoding Malleation (S/MIME): Exploiting the difference between DER (Distinguished Encoding Rules) and BER (Basic Encoding Rules) in ASN.1. S/MIME signatures are CMS structures requiring canonical DER encoding. The author rewrites a length field within the CMS envelope from its canonical short form to an equivalent non-canonical long form (e.g., encoding length 32 as 0x81 0x20 instead of 0x20). While this violates strict DER rules, it remains valid BER. The signature value and signed content remain untouched, preserving verification.

Key Contributions

Technique Characterization: The paper defines and demonstrates three malleation routes (mathematical, structural, and encoding) that cover all signature schemes supported by GitHub GPG verification (ECDSA, RSA, EdDSA, and S/MIME/CMS).
Server-Side Validation: The author shows that these are not merely local parser quirks. GitHub's server-side verifier accepts all three malleation techniques. Consequently, the forge issues independent, persistent "Verified" records for both the original and the malleated commits, keyed by their distinct hashes.
Impact Analysis: The paper analyzes the consequences for systems relying on commit hashes as content-addressable primary keys, including:
- Hash-based Blocking: Incident response tools that block specific commit hashes can be bypassed by pushing the malleated "ghost" commit, which has a different hash but identical content.
- Dependency Pinning: While full-SHA pinning (e.g., in Go modules or Nixpkgs) retains integrity against content substitution, the malleability creates aliasing at the signed-content level. Lockfiles regenerated from mirrors may record the "ghost" hash, leading to duplicate cache entries or inconsistent provenance records.
- Reproducible Builds: Systems treating the commit hash as the immutable revision identifier (e.g., SLSA Source Track, Sigstore Gitsign) are weakened. A single piece of content can generate multiple "Verified" anchors in transparency logs, duplicating rather than defending the trust anchor.
Proof-of-Concept Tooling: The author provides open-source tooling (interactive-malleator.py and setup-ghost.py) that automates these techniques, rewrites descendant commit chains to maintain graph consistency, and verifies the results against local and remote forges.

Results

Local Verification: All three techniques pass local verification using git verify-commit for OpenPGP-based schemes (ECDSA, RSA, EdDSA). For S/MIME, strict local parsers (like gpgsm using libksba) reject the non-canonical DER encoding, but GitHub's more permissive parser accepts it.
GitHub Acceptance: GitHub accepts all three malleation methods. The platform does not canonicalize signature containers before verification. As a result, a single logical commit can be represented by an unbounded family of byte-distinct hashes, each marked "Verified" and presented as unrelated history in comparison views (e.g., "1 commit ahead and 1 commit behind").
Persistence: The "Verified" status is durable. Even if the signing key is rotated or revoked, the malleated commits retain their independent verification records because the forge keys the record to the specific commit hash, not the content or key state.

Significance
The paper concludes that the assumption that a signed, verified commit hash is a unique handle for a specific piece of content is false. The attack does not rely on hash collisions or content forgery but rather on the malleability of the signature encoding itself. The practical significance is that systems relying on commit hashes for blocking, dependency pinning, and reproducible build verification are vulnerable to equivocation. The author argues that trust should not be placed in the raw hash of a signed object whose encoding an adversary controls; instead, systems must canonicalize and verify content before treating the hash as a unique identifier. The paper notes that as of the writing date, the issue remains unaddressed by Git or major Git forges.

The Great Digital Identity Swap

The Three Ways to Trick the System

Why This Matters: The "Ghost" Problem

The Verdict

Technical Summary: Git Hash Chain Malleability

More like this