A groundbreaking new research paper has unveiled a significant vulnerability in how leading software development platforms, including GitHub, interpret and display the "Verified" status for signed Git commits. Contrary to widespread assumption within the software world, a signed Git commit’s hash is not the immutable, one-of-a-kind identifier for its contents that many systems treat it to be. This discovery reveals that an attacker, without possessing the original signing key, can generate a second, distinct commit hash for an identical set of files, author, and date, while still maintaining a valid cryptographic signature that platforms like GitHub will stamp as "Verified." This phenomenon, dubbed "hash chain malleability," has profound implications for software supply chain security, provenance tracking, and the reliability of hash-based security controls.
The core of the issue lies in the malleability of cryptographic signatures and the subsequent impact on the commit’s hash. In a standard Git workflow, developers sign commits using GPG or S/MIME keys to assert authorship and integrity. Platforms like GitHub then display a "Verified" badge next to these commits, signaling to reviewers and automated systems that the commit originated from a trusted source and its content has not been tampered with since signing. This verification often leads to the implicit assumption that the commit’s unique SHA-1 (or increasingly, SHA-256) hash acts as a permanent and unalterable identifier for its specific content and metadata. However, the new research demonstrates that this assumption is flawed. An attacker can take any legitimately signed commit, subtly alter the raw bytes of its valid signature in a way that doesn’t invalidate the signature itself, but crucially changes the overall hash of the commit object. Since the commit’s content (files, author, date) remains identical, the forged commit appears indistinguishable to a human reviewer, yet its distinct hash allows it to bypass security mechanisms reliant on unique hash identification.
Understanding Git’s Integrity Model and Digital Signatures
To fully grasp the gravity of this vulnerability, it is essential to understand the foundational principles of Git and cryptographic signatures in modern software development. Git, as a distributed version control system, relies heavily on cryptographic hashing to ensure data integrity and track changes. Every object in Git—be it a file (blob), a directory structure (tree), or a commit—is identified by a unique SHA-1 hash of its content. A commit object, specifically, encapsulates a snapshot of the repository’s files (via a tree object), references to its parent commits, the author’s and committer’s metadata (name, email, timestamp), and the commit message. The hash of a commit is computed over all these elements, including any embedded digital signature.
Digital signatures, typically implemented using GPG (GNU Privacy Guard) or S/MIME (Secure/Multipurpose Internet Mail Extensions), are added to Git commits to provide authenticity and non-repudiation. When a developer signs a commit, they use their private key to create a cryptographic signature over the commit’s data. Anyone with the corresponding public key can then verify this signature, confirming that the commit indeed originated from the claimed author and that its content has not been altered since it was signed. Platforms like GitHub automate this verification process, displaying the "Verified" badge as a quick visual indicator of a commit’s authenticity. This badge is often considered a critical trust signal, especially in security-sensitive projects, open-source contributions, and corporate development pipelines. The integrity model implicitly suggests that a verified commit hash uniquely identifies a specific, immutable state of the codebase, signed by a known entity.
The Mechanism of Hash Chain Malleability
The research, conducted by Jacob Ginesin, a PhD student at Carnegie Mellon University and a cryptographic auditor at Cure53, meticulously details how this integrity model is undermined. Ginesin’s paper, published on arXiv on July 2, 2024, and accompanied by a public tool and demo repositories on GitHub, demonstrates the practicality of these attacks. The core vulnerability stems from what Ginesin terms "signature malleability." Cryptographic signatures, particularly those using algorithms like ECDSA (Elliptic Curve Digital Signature Algorithm), can often be represented in multiple valid forms. While these different forms all correctly verify against the same public key and message, their raw byte representations differ. Since a Git commit’s hash is computed over all its contents, including the raw bytes of the digital signature embedded in its header, subtly changing these signature bytes (without invalidating the signature) results in a completely different commit hash, even if the actual code and all other metadata remain identical.
This leads directly to "hash chain malleability." In Git, each commit inherently names its parent commit by hash. If an attacker successfully malleates a signed commit, creating an identical twin with a different hash, this change necessarily cascades up the commit history. Any subsequent commits in that branch, which reference the original (now malleated) commit as their parent, would also need their parent pointers updated to the new, malleated hash. If these descendant commits were themselves signed, altering their parent pointer would invalidate their own existing signatures, causing them to lose their "Verified" badge unless they are re-signed. Ginesin’s tool addresses this by rewriting the entire chain to keep it consistent, demonstrating the feasibility of propagating these changes while maintaining signature validity where possible.
The enabler for this malleability on platforms like GitHub is their current signature verification process. GitHub, the research highlights, does not normalize signatures before checking them. This means it accepts various valid encodings for S/MIME signatures, tolerates non-canonical ECDSA values, and does not strictly strip non-essential OpenPGP fields. By accepting these diverse, yet cryptographically valid, representations of a signature, GitHub inadvertently allows for the creation of multiple distinct commit hashes for the same signed content. Once GitHub files a "Verified" record against a specific commit hash, it does not re-check it, meaning a commit can remain "Verified" even if its signing key is later revoked or if a malleated twin exists. The platform’s compare view further illustrates the problem, treating an original commit and its malleated twin as divergent histories—one commit ahead and one behind—despite their identical file contents.
Wider Implications for Software Security and Supply Chain Integrity
The implications of hash chain malleability are far-reaching, particularly in the context of modern software development and supply chain security.
- Bypassing Security Blocklists: One of the most immediate concerns is the circumvention of hash-based blocklists. Organizations often maintain lists of known malicious commit hashes to prevent their introduction into production systems. With this vulnerability, an attacker can simply re-push the same malicious content under a new, still-"Verified" hash that has never been seen by the blocklist, rendering such defenses ineffective.
- Compromised Deduplication and Provenance Logs: Systems relying on commit hashes for deduplication purposes—to save storage or bandwidth—will fail to identify identical content, potentially leading to inefficiencies or missed security detections. Similarly, provenance logs, which track the origin and evolution of code through its commit hashes, lose their integrity. A malleated commit could obscure the true lineage or identity of code, making it harder to audit or trace back to its source.
- Undermining Reproducible Builds: Reproducible build systems aim to ensure that given the same source code, the build process always yields the exact same binary output. Many such systems rely on unique commit hashes to identify the precise source state. If a single source state can have multiple valid commit hashes, it complicates the guarantee of reproducible builds and the trust placed in their outputs.
- Trust in "Verified" Badges: The "Verified" badge, intended as a robust signal of trust, loses some of its weight. While it still confirms the commit was signed by a legitimate key, it no longer guarantees that the specific hash represents a unique, immutable instance of that signed content. This subtle distinction can be easily overlooked by developers and automated tools, leading to a false sense of security.
- Hostile Mirror Attacks: A compromised or hostile Git mirror could exploit this vulnerability by serving validly signed commits whose hashes differ from those on the canonical forge. While the content would remain identical, the differing hashes could cause confusion, break automated checks, or allow for subtle, untraceable disruptions in development workflows.
It is crucial to emphasize what this vulnerability is not. It is not a hash collision; it does not break the cryptographic strength of SHA-1 or SHA-256. The vulnerability does not allow an attacker to slip different code past a signature check. The files themselves remain identical in every copy. Therefore, if a system or developer has pinned to a specific commit hash, that hash will still fetch precisely the content expected, or fail if the content doesn’t match the hash. The issue lies squarely in the assumption that a validly signed commit hash is a unique identifier for its content, an assumption which proves false due to signature malleability.
Historical Precedent: Lessons from Bitcoin’s Transaction Malleability
Ginesin’s research draws a powerful parallel to a well-known vulnerability that plagued Bitcoin years ago: transaction malleability. In Bitcoin’s early days, anyone could flip the ‘s’ value in an ECDSA transaction signature to create a different, but still valid, signature. This change would alter the transaction’s unique ID (which was derived from the transaction’s content, including the signature) without invalidating the transaction itself. This malleability posed significant problems, particularly for transaction chaining and unconfirmed transaction tracking, as a party could claim a transaction wasn’t broadcast or confirmed if its ID changed, even if the funds were moved.
The Bitcoin community addressed this issue through two primary mechanisms:
- Canonicalization: Initially, by enforcing a "low-S" form for ECDSA signatures, meaning only one specific valid representation of the ‘s’ value was accepted.
- Segregated Witness (SegWit): A more fundamental change that moved transaction signatures out of the data used to compute the transaction ID, thereby making the transaction ID immutable regardless of signature variations.
This historical context is vital because it highlights that the problem of signature malleability is not new or esoteric; it is a "known lesson" in cryptography. The fix, as proposed by Ginesin, rhymes with these past solutions: canonicalize the signature encoding before trusting the hash or verifying the signature. This involves ensuring that only one specific, standardized representation of a valid signature is accepted, thereby eliminating the possibility of generating multiple hashes for the same signed content.
Timeline and Disclosure
Jacob Ginesin followed responsible disclosure practices, reporting the issue to relevant parties well in advance of public disclosure. He informed GNU and Git project maintainers in January 2024, followed by a report to GitHub in March 2024. As of the publication of his paper on July 2, 2024, Ginesin noted that neither Git nor any major forge had publicly addressed the vulnerability or implemented a fix. The public release of the paper, tool, and demo repositories serves to raise awareness and encourage prompt action from affected platforms and tooling developers.
Statements and Recommendations
While official statements from GitHub or Git are pending as of the paper’s publication, the implications for these platforms are clear. Ginesin’s research implicitly calls upon code hosting platforms (forges) to re-evaluate their signature verification processes.
Recommendations for Forges (e.g., GitHub):
The primary responsibility for implementing a fix lies with the forges. They should:
- Canonicalize Signatures: Implement strict canonicalization rules for all accepted signature formats (GPG, S/MIME, ECDSA) before performing verification and associating a "Verified" status with a commit hash. This ensures that only one specific, standardized representation of a valid signature is accepted, preventing hash malleability.
- Re-evaluate "Verified" Semantics: Consider clarifying or adjusting the meaning of the "Verified" badge to explicitly state what it guarantees and what it does not, particularly regarding the uniqueness of the commit hash.
Recommendations for Tooling Developers and Organizations:
Beyond the forges, any system that relies on commit hashes for critical security or integrity functions should also adapt:
- Canonicalize Before Trusting Hashes: Tools used for blocking malicious commits, deduplication, or recording provenance should incorporate signature canonicalization into their verification processes. They should not solely trust the raw hash of a signed object if that object can be re-encoded.
- Layered Security: Organizations should adopt layered security approaches. For example, systems that pin an independent hash of the fetched files (not just the commit object), such as Nix’s fixed-output derivations, offer a robust backstop against this type of vulnerability. These systems effectively verify the content independently of the commit metadata and signature, providing an additional layer of assurance.
- Continued Vigilance for CI/CD: The advice to "pin to a full commit hash, not a movable tag" for GitHub Actions and other CI/CD workflows still holds. This practice, critical after previous incidents like the 2025
tj-actions/changed-filesand 2026trivy-actionattacks, ensures that specific code versions are used. However, Ginesin’s research adds a crucial nuance: while pinning prevents code changes, relying solely on a "Verified" commit hash as a unique content identifier without considering malleability is a soft spot.
Broader Impact and Future Outlook
This discovery underscores the continuous and evolving challenges in securing the software supply chain. As dependencies grow and development workflows become more complex, the integrity of fundamental tools like Git and the trust signals provided by platforms become paramount. Ginesin’s work serves as a powerful reminder that even widely accepted security assumptions, such as the uniqueness of a cryptographically signed hash, must be rigorously tested and validated.
The "forge-side fix is well understood," as the paper notes, drawing from established cryptographic practices. The most obvious starting point for implementation is the S/MIME case, where GitHub currently accepts what a strict local check would reject. This vulnerability is not an indictment of Git’s core design or cryptographic algorithms, but rather a highlight of implementation details in how platforms process and present cryptographic assurances. It reinforces the critical role of academic research and independent security audits in identifying practical vulnerabilities that might otherwise go unnoticed. As the software world increasingly relies on automated security checks and supply chain integrity measures, addressing issues like hash chain malleability will be crucial for maintaining trust and preventing sophisticated attacks. The community now awaits official responses and remediation efforts from the affected platforms to bolster the security foundations of modern software development.
