GitHub 'Verified' Commits Can Be Cloned Into New Hashes Without the Signing Key

A signed Git commit's hash is not the unique name most of the software supply chain assumes it is. Research published July 2 by Jacob Ginesin, a Carnegie Mellon PhD student and cryptographic auditor at Cure53, shows that anyone can take a signed commit and, without the signing key, produce a second commit with the same files, same author, same date, and a valid signature that GitHub stamps 'Verified.' Only the hash differs. Ginesin's five-page arXiv paper ships with a public tool that runs all three attack variants and two demo repositories where the rewritten commits still display the Verified badge on GitHub today.

The practical failure is immediate: if you block a malicious commit by hash, an attacker re-pushes the identical content under a fresh, still-Verified hash your blocklist has never seen. Deduplication systems, provenance logs, and reproducible-build records that key on commit hashes all inherit the same soft spot. A compromised mirror can serve cloners validly signed commits whose hashes do not match the canonical forge, and GitHub's own compare view treats the twins as divergent histories despite byte-identical trees.

Three routes, every scheme covered

The root cause is signature malleability. A commit's hash covers everything in the commit object, including the raw bytes of the signature itself. Many signature formats can be rewritten into a different but still-valid encoding, and changing those bytes changes the hash without touching a line of code. Ginesin demonstrates one route per scheme, together covering every GPG type GitHub verifies plus S/MIME:

• ECDSA: flip the signature's s value to n − s, a classic elliptic-curve symmetry. Both forms verify. Passes local git verify-commit and earns the GitHub badge.
• RSA and EdDSA: append anextra, ignored field to the signature's unhashed section, the part the signature deliberately does not cover. The signature still checks out; the bytes and hash change. Local and GitHub both accept it.
• S/MIME (X.509): rewrite a length field in the DER structure into a longer, non-standard form. A strict local check via gpgsm rejects it, but GitHub still marks it Verified.

The common enabler is that GitHub does not normalize a signature before verifying it: no strict DER encoding for S/MIME, no stripping of the OpenPGP unhashed fields, and non-canonical ECDSA values accepted as-is. GitHub then files a Verified record against each commit hash and never re-checks it, so a commit stays Verified even after its signing key is revoked.

Hash chain malleability

Because every commit names its parent by hash, malleating one commit forces new hashes on every commit above it. Ginesin's tool rewrites that chain to keep it consistent, an effect he calls 'hash chain malleability.' There is a catch for attackers: a signed descendant loses its own badge the moment its parent pointer changes, because the child's signature was made over the old parent hash. The malleation propagates, but the verified status does not automatically follow it up the chain.

Bitcoin already fought this

The core move is old. Bitcoin faced the identical ECDSA symmetry years ago, when anyone could flip the s value in a transaction signature and change the transaction ID without the owner's key. The fix was to accept only the low-S form, and later to move signatures out of the ID entirely with SegWit. Ginesin's recommended fixes rhyme with that: canonicalize the signature encoding before you trust the hash. This is a known lesson, not exotic new cryptography, which makes the absence of a forge-side fix harder to excuse.

How this connects to the Actions tag hijacks

The paper ties the work to the recent GitHub Actions supply-chain incidents, the 2025 tj-actions/changed-files compromise and the 2026 trivy-action attack it cites. The guidance after those was to pin to a full commit hash rather than a movable tag, and that advice still holds; pinning stopped those attacks and this research does not change that. The narrower point is a caution against a specific tell. In the Trivy case, the malicious commits stood out because they could not be validly signed. Ginesin's work shows why you should not lean too hard on that signal: a valid signature proves who signed a commit, but it does not make the commit's hash a one-of-a-kind name for its contents.

Who has to act

Not the developer pinning an Action or a module. A pinned hash still fetches the right code, and there is nothing to change in your own repository. The work belongs to the forges: canonicalize signatures before trusting them. Any tooling that blocks, deduplicates, or records provenance by commit hash should do the same, verifying and canonicalizing first rather than trusting the raw hash of a signed object an attacker can re-encode. Exposure is uneven: schemes that also pin an independent hash of the fetched files, such as Nix fixed-output derivations, keep a backstop; systems that stop at a verified commit hash do not.

For security and IT teams, the action item is an inventory question, not a patch: find every place a decision hangs on a verified commit hash being unique, blocklists, dedup, provenance, and reproducible-build attestations, and confirm each one canonicalizes and independently verifies content rather than trusting the raw hash of a signed object. Until forges ship normalization, treat a Verified badge as proof of authorship only, never as proof that a hash is the single canonical name for what it points to.