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

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

The article reports research showing that GitHub’s "Verified" badge for signed commits can be preserved even when an attacker rewrites a commit into a new hash with identical contents, metadata, and a still-valid signature, so that reviewers see matching author, files, date, and a "Verified" status while the underlying commit identity has changed.[5][8] This undermines assumptions that a commit hash plus a "Verified" badge uniquely and immutably identifies trusted code in the broader software supply chain. From a RealGround perspective, this affects AI supply chain integrity: models and AI agents built from code or data pulled from GitHub cannot rely solely on "Verified" commits as a tamper-proof provenance signal, increasing risk of subtle code or dependency substitution attacks. Organizations should augment commit verification with end-to-end content integrity checks, SBOM-based provenance, and continuous red teaming of CI/CD and model build pipelines to detect supply chain manipulation that abuses Git commit semantics and GitHub’s verification model.