GitHub’s Green Badge Meets a Hard Problem: Identity That Can Be Rewritten
Research tied to signed commits suggests that a trusted-looking hash can change while GitHub still shows “Verified,” forcing teams to rethink what their review process really proves.
Introduction
A commit signature is supposed to answer a simple question: did a trusted key approve this change? The new finding attached to GitHub’s verification flow complicates that picture. In the scenario described, a signed Git commit can be reconstructed into a different hash while keeping the same visible contents, author details, date, and a valid signature.
That matters because many workflows treat the hash as a stable name for a specific signed object. Netcrook’s reading is narrower than the headline drama: this is not proof that Git itself is unusable, but it is a reminder that a verification badge and a hash value do not always mean the same thing.
Fast Facts
- A signed Git commit can be rewritten into a different hash.
- The rewritten commit can preserve the same files, author, and date.
- GitHub may still display the rewritten commit as “Verified.”
- The issue challenges the assumption that a commit hash uniquely identifies a signed commit.
Body
The technical takeaway is specific but important. A valid signature shows that a signing key approved some commit object. The hash shows the final digest of that object. If a second object can be minted with the same visible metadata and still pass verification, then the hash alone is not enough to prove that a reviewer is looking at the only possible signed version of that change.
That distinction can matter in code review, compliance checks, and release coordination, especially when teams use the hash as shorthand for identity. The reported behavior does not automatically mean malicious tampering occurred in the wild, and it does not establish that downstream systems were affected. It does show why security teams should be careful about assuming that a green badge settles every question about provenance.
At the time of writing, public information has not fully established the exact technical method, the broader scope of the behavior, or whether any real-world abuse followed. The available information supports a risk analysis, not a conclusion of widespread compromise.
From a defensive perspective, the lesson is modest but practical: commit hashes, signatures, and platform verification are related checks, not interchangeable ones. Teams may want to review how those signals are interpreted in internal workflows, especially where a single approved identifier is treated as final proof of trust.
Conclusion
The broader lesson is that software trust is layered, and each layer can answer only part of the question. When a verified commit can still be rewritten into a different hash, the safe habit is to treat verification as evidence, not as the end of the investigation.
TECHCROOK
hardware security key: A hardware security key adds a physical factor for logins and repository access. It is a practical option for developers and admins who want stronger protection than passwords alone when handling code, signing, and account recovery.
WIKICROOK
- Commit hash: a digest that changes when the commit object changes.
- Signed commit: a Git commit paired with a cryptographic signature from a private key.
- Verified badge: a platform label showing that a signature check passed.
- Signing key: the private key used to create a digital signature.
- Provenance: evidence showing where code came from and how it was produced.
