How the Attack Works
New research reveals a fundamental flaw in how GitHub validates signed commits. A signed Git commit’s hash can be rewritten into a new, valid hash without altering the file contents, author, or date, and GitHub still displays its signature as “Verified.” This happens because GitHub does not normalize signatures before checking them. An attacker without the signing key can mint a second commit with identical content but a different hash, and both will appear verified on the platform.
The attack exploits signature malleability across multiple cryptographic schemes. For ECDSA keys, the classic elliptic-curve algebra of flipping the signature’s S value works. For RSA and EdDSA keys, an attacker can add an extra ignored field to the signature’s unhashed section. For S/MIME keys, rewriting a DER length field into a non-standard form can bypass GitHub’s check even when a strict local tool rejects it. The researcher, Jacob Ginesin from Carnegie Mellon University and Cure53, released a public tool and two demo repositories showing commits that still appear verified after malleation.
Impact and Remediation
The most concrete risk is that hash based blocklists and provenance systems become unreliable. An attacker whose commit hash is blocked can re push the same malicious content under a fresh verified hash that bypasses the blocklist. Systems that deduplicate, log provenance, or record reproducible builds using commit hashes inherit the same weakness. However, the files themselves remain identical, so a pinned hash still fetches the correct content.
The fix must come from the forges, not from individual developers. The paper recommends that GitHub and other forges canonicalize signatures before trusting them, similar to how Bitcoin resolved ECDSA symmetry by accepting only the low S form. Tooling that blocks or records provenance by commit hash should verify and canonicalize first rather than trusting the raw hash of a signed object. As of publication, neither Git nor any forge has addressed the issue, though the S/MIME case is the most urgent since GitHub still accepts what a strict local check rejects.
Source: The Hacker News
