GitHub's Green 'Verified' Badge Can Lie: Signed Commits Cloned Without the Key

Key points

• New research shows a signed Git commit's hash, the unique fingerprint that identifies it, is not as unique as almost every developer assumes.
• An attacker without the signing key can produce a second commit with identical files, author and date, still marked "Verified" by GitHub.
• The trick breaks the assumption that a commit hash safely names one specific piece of code, which matters for audits, supply chain checks and incident forensics.
• Reviewers looking at author, date, message and signature will see everything match; only the hash differs.
• The finding, surfaced by The Hacker News, affects any workflow that trusts a commit ID as a tamper-proof reference.

Git, the software that tracks changes to code across most of the world's development teams, gives every change a long string of letters and numbers called a hash. That hash is supposed to be a fingerprint. If two hashes match, the code and its history are meant to be identical. If they differ, something has changed.

That quiet assumption is now on shakier ground.

New research demonstrates that a signed commit, the kind marked with GitHub's green "Verified" badge, can be duplicated by someone who does not have the original developer's signing key. The copy carries the same files, the same author name, the same timestamp, and a signature GitHub happily accepts. The only thing that changes is the hash itself.

In practice, that means the fingerprint is no longer a reliable name for a specific piece of code.

Why does this matter to anyone outside a dev team?

Because a lot of security depends on that fingerprint being trustworthy. Companies audit which exact code went into production by writing down commit hashes. Automated build systems pull a specific hash to make sure they are shipping the reviewed version. Regulators and incident responders point at hashes when they say "this is the code that ran on the day of the breach."

If two different commits can wear the same signed identity while showing different fingerprints, those records get slippery. A reviewer skimming a pull request will see the author they trust, the date they expect, and the reassuring green Verified badge. They will not notice that the hash they are looking at is not the hash that was reviewed last week.

How the trick works, in plain terms

A Git commit is essentially a small text record: who made the change, when, what the message said, and pointers to the files. The signature covers that record.

The research shows there is enough wiggle room in how that record can be formatted that a second, valid version can be built. The signature still checks out because the fields it protects have not meaningfully changed. But the way the whole thing is packaged shifts just enough to produce a different hash.

Think of it like two envelopes with the same letter inside and the same signature on the letter, but slightly different handwriting on the outside. The postal system gives them different tracking numbers. The letter reads the same.

What GitHub sees, and what it misses

GitHub's Verified badge answers one question: does the signature match a known key for this author? It does not, and was never designed to, guarantee that the commit hash you are looking at is the only possible signed version of that content.

The failure mode here is a mismatch between what developers assume the badge means and what it actually proves. Most people read "Verified" as "this exact commit, hash and all, came from this person." The reality is narrower.

What should teams do now?

Stop treating a commit hash alone as proof of provenance. Pin dependencies by hash and signature together, and record the signing key ID in your audit trail, not just the hash. If your release process says "we shipped commit abc123," add "signed by key X, verified against fingerprint Y" alongside it.

For ordinary GitHub users there is nothing to patch and no password to change. The Verified badge is not broken, it just means less than most people thought.

One thing the post-mortem will say, eventually: we trusted a label instead of reading what it actually promised.