FHN 
A recently disclosed security finding has revealed that attackers can create duplicate “Verified” GitHub commits by exploiting a technique known as signature malleability. Although the duplicated commit is assigned a different hash, it contains the same source code, remains cryptographically valid, and continues to display GitHub’s trusted “Verified” badge.
This discovery challenges a long-standing assumption within Git—that a verified commit hash uniquely identifies a specific piece of signed code. As a result, organizations that rely on commit hashes for software integrity, dependency management, CI/CD validation, or software supply chain security should carefully evaluate the potential impact of this issue.
How the Attack Works
Git generates a unique hash for every commit using multiple components, including the source code, author and committer information, commit message, parent commit, and the embedded digital signature.
Under normal circumstances, modifying any part of a commit results in a completely different hash. However, researchers found that certain digital signature formats allow the signature’s encoded representation to be modified without affecting its cryptographic validity.
By changing only the encoding of the signature—not the source code or commit metadata—attackers can generate a new commit hash while preserving the same content and a valid signature. GitHub continues to verify the modified commit successfully and displays the familiar “Verified” badge.
As a result, two different commit hashes can represent the same code, making both appear as separate trusted commits.
Why This Matters
Many organizations use commit hashes as trusted identifiers throughout their software development lifecycle. Security tools, CI/CD pipelines, dependency management systems, and software supply chain controls often assume that every verified commit hash is unique and immutable.
This research demonstrates that the assumption may not always hold true.
An attacker could recreate an existing verified commit with a different hash, potentially bypassing security controls that rely solely on commit hashes. Systems designed to block malicious commits, enforce dependency pinning, or verify source code integrity may fail to recognize the duplicated commit because it appears as a new trusted object.
Research Findings
Security researcher Jacob Ginesin demonstrated several practical techniques affecting multiple GitHub-supported signature formats, including:
- ECDSA
- RSA (OpenPGP)
- EdDSA
- S/MIME/CMS
The research shows that GitHub currently accepts these modified signatures during verification and continues to mark the resulting commits as Verified, even though their hashes differ from the originals.
Since GitHub validates the cryptographic signature rather than enforcing a canonical signature encoding, these modified commits continue to pass the verification process successfully.
Potential Impact
The implications extend beyond individual repositories and may affect broader software supply chain security practices.
Potential risks include:
- Bypassing hash-based security controls.
- Circumventing commit blocklists by generating new verified hashes.
- Misleading dependency pinning mechanisms that rely on commit hashes.
- Creating confusion during repository comparisons and code reviews.
- Weakening software supply chain verification processes.
- Affecting reproducible build and software provenance frameworks that treat commit hashes as trusted identifiers.
Because Git commits are linked through parent commit hashes, modifying a signed commit also changes the hashes of all subsequent commits, allowing attackers to generate an entirely new yet valid-looking commit history.
Security Recommendations
Until stronger mitigations are introduced, organizations should avoid relying solely on commit hashes when validating software integrity.
Consider adopting the following security practices:
- Validate both commit content and digital signatures instead of relying only on commit hashes.
- Monitor repositories for unexpected duplicate verified commits.
- Strengthen CI/CD validation with multiple layers of verification.
- Review dependency pinning strategies that depend exclusively on commit hashes.
- Keep GitHub security features and repository protection settings up to date.
- Monitor security advisories and implement recommended mitigations as they become available.
Final Thoughts
This research serves as an important reminder that a “Verified” badge alone should not be considered the sole indicator of trust. While digital signatures remain a critical component of software integrity, organizations should implement layered verification processes that validate both the authenticity of the signature and the integrity of the underlying code.
As software supply chain attacks continue to evolve, strengthening repository security, enhancing CI/CD validation, and adopting defense-in-depth strategies will be essential to maintaining trust in modern software development workflows.
About the Author
Your LLM-in-the-loop agent_submit system for automated blog comments is a fascinating approach to scaling link-building while maintaining authenticity. At APIVALE, as we route multi-model API workloads, we’ve seen similar challenges with balancing automation and anti-spam detection, especially with persona rotation and IP diversity. Given the 0-5% survival rate for comments, how do you decide when to cut losses on a domain versus investing more in personalized content generation?