Fast Facts
- Attackers can create multiple valid, signed commits with different hashes, allowing them to bypass blocklists and provenance checks that rely solely on commit hashes.
- GitHub’s acceptance of signature malleability enables malicious commits to appear "Verified" despite altered signatures, undermining trust in commit authenticity.
- Existing systems that only verify commit hashes are vulnerable; they can be exploited by re-encoding signatures without invalidating the commit content, posing risks to software integrity and security.
Threat Overview, Attack Techniques, and Targets
Recent research reveals that committed signatures on GitHub can be manipulated. Attackers can create a new commit with the same files, author, and date, but a different hash that still appears verified. This is possible because the commit’s signature can be altered without changing the actual content. The main technique involves signature malleability, where signature bytes are rewritten, and the commit’s hash remains valid under verification. The routes include altering ECDSA, RSA, and S/MIME signatures. For example, flipping the s value in ECDSA or adding ignored fields in RSA. Additionally, rewriting length fields in S/MIME signatures can produce valid but different signatures. Targets are repositories with signed commits marked as verified by GitHub. The flaw affects systems that rely solely on commit hashes for verification and provenance tracking.
Impact, Security Implications, and Remediation Guidance
This vulnerability allows attackers to replace verified commits with malicious but valid copies, which can bypass blocklists, provenance logs, and other security checks based on commit hashes. There is no evidence that this affects the cryptographic strength of SHA-1 or SHA-256 itself. Instead, it exploits the way signatures are verified without normalization. The primary implication is that “Verified” labels on GitHub does not guarantee the integrity of the commit’s signature or its unique identity.
As a result, trust in verified commits can be undermined. To mitigate risks, developers should pin exact commit hashes instead of using tags. The fix must come from the forge side by canonicalizing signatures before trusting them. Users should verify signatures before trusting them, especially in critical workflows. For systems that depend heavily on commit hashes for provenance, additional safeguards are recommended. Since no official vendor advisories exist yet, it is advised to consult security experts or the software provider for specific remediation steps.
Stay Ahead with the Latest Tech Trends
Stay informed on the revolutionary breakthroughs in Quantum Computing research.
Stay inspired by the vast knowledge available on Wikipedia.
ThreatIntel-V1
