Researchers have disclosed a fundamental cryptographic weakness in GitHub's commit verification system. Attackers can create multiple commits with identical content, author information, and timestamps, each producing a different hash while retaining valid signatures that GitHub marks as "Verified."
The attack exploits how Git constructs commit hashes. A commit hash derives from the commit's contents plus metadata. Git signatures verify only the commit's contents, not the hash itself. This creates a gap. An attacker without the signing key can modify non-cryptographic commit fields, such as the committer timestamp or name formatting, generate a new hash, and produce a valid signature using the original signer's key through Git's flexible signing mechanisms.
The risk cuts deep into supply chain security. Developers reviewing code rely on commit hashes to identify specific versions. If multiple hashes can represent the "same" commit with matching signatures, attackers can swap commits in repositories without breaking cryptographic verification. A malicious actor could replace a reviewed commit with another bearing the same author, date, and message but containing injected code. GitHub's "Verified" badge provides false assurance.
This affects any workflow dependent on commit hash immutability. CI/CD pipelines, audit trails, and reproducible builds all assume one hash equals one specific commit. The vulnerability potentially allows attackers to inject malicious code into open source projects, alter historical records, or bypass access controls tied to specific commit identifiers.
The weakness stems from Git's design, not GitHub alone. However, GitHub's verification badge misleads users into trusting commits they believe are immutable. The platform should clarify that verification guarantees only that a key signed the commit's contents, not that no other commits with identical appearance exist.
Organizations should audit their reliance on commit hashes for security decisions. Code review tools, container image tagging systems, and release pipelines should implement additional verification layers beyond signature checking.