Title: Vulnerability in GitHub’s Verified Commit System Exposes Software Supply Chains to Attacks
Recent findings reveal a critical vulnerability in GitHub’s commit verification system that allows attackers to clone "Verified" commits without altering the actual content. The exploit arises from malleability in Git’s commit-signing formats, allowing individuals to create byte-different commits that carry valid signatures and a fresh "Verified" badge. This development undermines the conventional belief that a verified commit hash is a secure, immutable identifier for a specific piece of signed content.
The Nature of the Vulnerability
Historically, Git’s security model has treated the commit hash as a content-addressable identifier, encapsulating critical components like the tree structure, parent list, author and committer metadata, commit messages, and the cryptographic signatures embedded in the gpgsig header. However, the signature’s placement within the hashed region presents an opportunity for exploitation. By modifying its byte encoding without altering the content it authenticates, attackers can produce various commit hashes while maintaining unbroken links to the original data.
This scenario exposes the reliability of hash-based blocking, dependency pinning, and reproducible-build workflows, leading to the possibility of supply-chain attacks. In this context, Jacob Ginesin’s research on "Git Hash Chain Malleability" highlights three practical methods of malleation applicable to all GPG-based signature schemes currently supported by GitHub, including ECDSA, RSA, EdDSA, and S/MIME/CMS.
Mechanisms of Attack
For instance, in the case of ECDSA signatures, a classical algebraic symmetry enables attackers to convert a valid signature pair into a new, equally valid signature using only public curve parameters. This transformation results in a second valid signature for the same commit payload—one that features different byte representations and thus a newly generated hash.
In contrast, for RSA and EdDSA signatures under OpenPGP, attackers can exploit the unhashed subpacket region to append non-critical experimental subpackets. This technique allows an attacker to create an altered version of the commit without raising suspicion.
One of the most alarming aspects is that GitHub’s server-side verification accepts all three of these malleation techniques. Each modified commit is logged as a unique, durable "Verified" entry, keyed solely to the new commit hash. Notably, GitHub does not canonicalize OpenPGP or CMS containers prior to verification. It allows non-standard ECDSA scalars, disregards advisory unhashed subpackets, and tolerates non-DER CMS envelopes as long as the foundational signature validates. This means that two “Verified” commits could encode identical content yet appear distinct from a verification standpoint.
Broader Implications
The ramifications of such vulnerabilities extend far beyond single commits. Since each Git commit references its parent via a hash, altering a signed commit necessitates updating all descendant commits and creating new hashes, even when their contents remain unchanged. Ginesin has crafted proof-of-concept tools capable of automatically detecting the signature type in the gpgsig header, implementing the appropriate malleation, rewriting descendant commits to maintain a coherent history, and adjusting branch pointers to the new head.
Demonstrations are available in public repositories, showcasing both S/MIME-signed and EdDSA-signed commits that have undergone this kind of manipulation, each still carrying a valid GitHub “Verified” badge.
The potential downstream effects on software supply chains are enormous. Hash-based controls and push-protection rules designed to block known malicious commits by their SHA can easily be circumvented. By simply pushing a ghost twin under a freshly minted "Verified" hash that falls outside of existing block lists, attackers can execute unauthorized code or alter software without detection.
Moreover, dependency pinning mechanisms that depend on commit hashes, such as Nix flakes or pinned GitHub Actions SHAs, may be misled by repositories that provide alternate, validly signed hash chains diverging from the canonical version yet seemingly trustworthy.
The Path Forward: Mitigation Strategies
In light of these vulnerabilities, it becomes clear that existing frameworks treating commit hashes as immutable are severely flawed. High-assurance Continuous Integration/Continuous Deployment (CI/CD) and supply-chain contexts must not consider a signed commit or a GitHub "Verified" badge as definitive identifiers for any content.
Moving forward, it is crucial that deduplication, blocking, and pinning mechanisms interrogate the content after it has been canonicalized and verified against its signature, rather than relying on raw signed object bytes—bytes that are now demonstrably vulnerable to subtle manipulations by malicious entities.
In conclusion, while the capabilities of platforms like GitHub have advanced the realm of software development, they also expose critical vulnerabilities that could be detrimental to software supply chains if left unaddressed. As the tech community continues to explore these vulnerabilities, significant changes must be implemented to safeguard the integrity of verified commits and bolster the security landscape of software development.