New Research: A "Verified" GitHub Commit Is NOT Unique
Home
Newsletter
Sponsor
About
Contact
Research
7 July 2026 at 17:42
New Research: A "Verified" GitHub Commit Is NOT Unique
Git identifies every object by a hash of its contents, and for a commit that hash covers the tree, the metadata, the message, and the raw bytes of any signature. A large amount of supply-chain machinery treats that hash as a unique, immutable name for a specific piece of signed content. Continuous-integration pipelines pin to it, dependency managers lock to it, and incident responders block or revert by it.<br>A new preprint by Jacob Ginesin of Carnegie Mellon University argues that this assumption breaks. According to the paper, given any signed commit, an attacker who does not have the signing key can produce a second, distinct commit with an identical tree, identical metadata, a valid signature, and a "Verified" badge from a forge such as GitHub. Only the commit hash changes. Because each commit names its parent by hash, the change cascades down the chain, which the author calls "hash chain malleability."<br>The mechanism is signature malleability, not a broken hash function. The paper is explicit that it does not exhibit two different contents sharing one hash, so the finding is unrelated to the collision resistance of SHA-1 or the SHA-256 migration Git is moving toward. Instead, one logical commit admits many byte-different but equally valid signed serializations, each hashing to a different value.<br>The paper describes three routes, together covering every GPG-based scheme GitHub verifies. For ECDSA, it uses the classic algebraic symmetry that turns a signature (r, s) into an equally valid (r, n-s). For RSA and EdDSA, which resist that trick, it appends a well-formed but ignored subpacket to the unhashed region of the OpenPGP signature packet, a region RFC 4880 says is not covered by the signature. For S/MIME, it re-encodes a length field inside the CMS structure into a non-canonical form that is invalid strict DER but still accepted as BER.<br>What turns these from local curiosities into a supply-chain concern, the paper says, is GitHub's server-side behavior. According to the research, GitHub does not canonicalize the signature container before verifying it, so it accepts the ECDSA inversion, the OpenPGP subpacket insertion, and the non-canonical S/MIME encoding, and issues each resulting commit its own durable "Verified" record keyed on the commit hash. GitHub's own documentation confirms the underlying feature: a commit retains its verified status based on the record created at verification time, even if the signing key is later revoked or expires. The paper notes that strict local verification is more mixed. It says git verify-commit accepts the two OpenPGP routes but rejects the non-canonical S/MIME encoding, which GitHub accepts anyway.
International Cyber Digest
Get the ICD Newsletter
Subscribe for source-forward cyber news, OSINT notes, breach updates, and analysis. Have evidence or a lead? Send it to ICD.
Subscribe<br>Send a tip
Subscribe
Get the ICD Newsletter: cyber news, OSINT notes, sources, and analysis.
Success
Great! Check your inbox and click the link
Error
Please enter a valid email address!
Latest posts
Fake MrBeast casino scam is running inside TikTok's verified Discord server
7 July 2026 at 19:22
Japanese Police Arrest 15yo Over ChatGPT-Assisted Cyberattack Against Bandai Channel
6 July 2026 at 20:31
Discord Tests Incode for Age Checks and Users Are Reading the Fine Print
6 July 2026 at 20:14
International Cyber Digest
Cybersecurity news, OSINT-backed investigations, and analysis on breaches, cybercrime, AI security, privacy, and digital threats.
Bluesky
Mastodon
You might also like