GitHub ‘Verified’ Commits Can Be Rewritten Into New Hashes Without Breaking Signatures

New research from Carnegie Mellon University PhD student Jacob Ginesin, also a cryptographic auditor at Cure53, reveals that GitHub’s ‘Verified’ commit badge can be attached to multiple distinct hashes for the same content, undermining the assumption that a verified commit hash is a unique identifier. The paper, posted to arXiv on July 2, 2026, demonstrates three attack vectors exploiting signature malleability in GPG and S/MIME schemes: ECDSA signatures can be flipped via elliptic-curve algebra; RSA and EdDSA signatures can have extra fields added to the unhashed section; and S/MIME DER structures can be rewritten with non-standard length fields. In all cases, the commit’s files, author, and date remain identical, and GitHub still displays ‘Verified.’ The flaw lies in GitHub’s failure to canonicalize signatures before verification, and the fix belongs on the forge side. The research does not break SHA-1 or SHA-256, nor does it allow different code to pass signature checks. It highlights that systems relying on commit hashes for blocklisting, deduplication, or provenance logs are vulnerable to attackers re-pushing the same content under a new verified hash. The paper connects this to recent GitHub Actions tag hijacks, including the 2025 tj-actions/changed-files and 2026 trivy-action attacks, but notes that pinning to full commit hashes remains effective. Ginesin reported the issue to GNU and Git in January 2026 and to GitHub in March 2026, but as of publication, no forge had addressed it.