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

Key points

• A signed Git commit's hash, the unique fingerprint meant to identify it, is not as unique as almost every developer assumes.
• Someone without the signing key can produce a second commit with identical files, author and timestamp, 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 reviews and incident forensics.
• Reviewers checking author, date, message and signature will see everything match; only the hash differs.
• The finding affects any workflow that treats a commit ID as a tamper-proof reference.

Git, the software that tracks code changes 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: matching hashes mean identical code and history. Diverging hashes mean something 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 without the original developer's signing key. The copy carries the same files, the same author name, the same timestamp, and a signature GitHub accepts without complaint. Only the hash itself shifts.

When the hash is no longer a reliable name for a specific piece of code, a lot of downstream trust collapses with it. Threat Vectr has tracked this territory closely: we've published 24 software supply chain stories in the last 90 days, and our earlier look at GitHub's npm overhaul showed a platform still working out where its responsibility for supply chain integrity ends.

Why does this matter to anyone outside a dev team?

Security depends on that fingerprint being trustworthy. Companies audit which exact code went into production by recording commit hashes. Automated build systems pull a specific hash to confirm they're shipping the reviewed version. Incident responders point at hashes when they say "this is the code that ran on the day of the breach."

Two different commits can now wear the same signed identity while showing different hashes. A reviewer skimming a pull request will see the author they trust, the date they expect, and the reassuring green badge. They won't notice that the hash on screen is not the hash 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.

There's enough flexibility in how that record can be formatted that a second, valid version can be constructed. The signature still checks out because the fields it protects haven't meaningfully changed. But the packaging shifts just enough to produce a different hash.

Think of it as two envelopes carrying the same letter, the same signature on the letter, but slightly different handwriting on the outside. The postal system assigns them different tracking numbers. The letter reads identically.

What GitHub sees, and what it misses

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

The failure here is a mismatch between what developers assume the badge means and what it actually proves. Most people read "Verified" as confirmation that this exact commit came from this person. The badge is narrower than that.

Should you worry about your own repos?

For ordinary GitHub users there's nothing to patch and no credential to rotate. The badge isn't broken; it just certifies less than most people thought.

Teams running audited or regulated pipelines should act now: pin dependencies by hash and signature together, and record the signing key ID in your audit trail alongside the hash. If your release process logs a commit reference, add which key signed it and when.

The post-mortem that follows the first real exploit of this will have a familiar line: the team trusted a label instead of reading what it actually promised.