Full Report
New research shows that a signed Git commit's hash is not the one-of-a-kind name that much of the software world assumes it to be. Given any signed commit, someone without the signing key can mint a second commit with the same files, author, and date, and a valid signature, GitHub still stamps "Verified." Everything a reviewer would check matches. The commit's hash does not. That matters
Analysis Summary
# Vulnerability: GitHub "Verified" Commit Hash Chain Malleability
## CVE Details
- **CVE ID:** N/A (No CVE assigned as of the report date)
- **CVSS Score:** N/A (Severity is context-dependent; impacts integrity of provenance logs)
- **CWE:** CWE-347: Improper Verification of Cryptographic Signature (specifically signature malleability)
## Affected Systems
- **Products:** GitHub (Web Forge Interface)
- **Versions:** Current production environment as of July 2026
- **Configurations:** Repositories using signed commits (GPG, S/MIME, SSH) where users or automated systems rely on the specific commit hash as a unique identifier for "Verified" content.
## Vulnerability Description
Research by Jacob Ginesin (CMU) identifies that Git commit hashes are malleable even when signed. This is not a hash collision, but rather a result of how Git calculates hashes: the hash is computed over the entire commit object, which includes the raw signature bytes.
Because certain cryptographic signatures are malleable (can be rewritten into a different valid form without the private key), an attacker can alter the signature's bytes. This results in a new, unique commit hash for the exact same file content, author, and date. GitHub’s backend fails to normalize these signatures before verification, erroneously labeling the "mutated" commit hash as "Verified."
**Technical vectors include:**
- **ECDSA:** Exploiting mathematical symmetry (flipping the *s* value).
- **RSA/EdDSA:** Inserting ignored fields into the "unhashed" section of an OpenPGP signature.
- **S/MIME:** Using non-standard DER length encoding.
## Exploitation
- **Status:** PoC available (developed by Jacob Ginesin)
- **Complexity:** Medium (requires understanding of cryptographic signature structures)
- **Attack Vector:** Network (Pushing to a repository or hosting a malicious mirror)
## Impact
- **Confidentiality:** None (The file contents remain the same)
- **Integrity:** Medium/High (Breaks blocklists, provenance logs, deduplication, and reproducible builds that rely on specific hashes to identify "known-good" or "known-bad" states)
- **Availability:** Low (Can cause divergent branch histories in GitHub’s "Compare" view)
## Remediation
### Patches
- no user-side patch available. The resolution requires GitHub and other Git forges to implement **signature normalization/canonicalization** before verifying and assigning the "Verified" badge.
### Workarounds
- **Pinned Content:** Continue pinning to specific hashes; the vulnerability does not allow an attacker to change the code *under* a pinned hash.
- **Strict Verification:** Use local command-line verification (e.g., `gpgsm` for S/MIME) which can be stricter than GitHub’s web UI.
## Detection
- **Indicators of Compromise:** Multiple different commit hashes appearing in a history that claim to represent the exact same file changes, author, and timestamp, all while maintaining "Verified" status.
- **Detection Methods:** Use the **git-chain-malleator** tool to audit repositories for malleated signatures. Compare the "canonical" forge history against mirrors to detect hash mismatches.
## References
- **Research Paper:** hxxps[://]arxiv[.]org/abs/2607.02820
- **PoC Tool:** hxxps[://]github[.]com/JakeGinesin/git-chain-malleator
- **News Source:** hxxps[://]thehackernews[.]com/2026/07/github-verified-commits-can-be.html