Git’s long‑standing trust model has been upended by a practical attack that silently clones “Verified” GitHub commits through signature malleability, allowing adversaries to create byte‑different commits that contain identical trees, metadata, and logically identical signatures yet carry fresh commit hashes and retain GitHub’s “Verified” badge.
The problem stems from the fact that Git includes signature bytes in the hashed commit object: verifiers verify that a signature cryptographically validates the payload but do not require a canonical encoding of the signature itself, so an attacker can alter the signature’s serialized form without changing the payload it attests to.
Recent research into “Git Hash Chain Malleability” demonstrates concrete malleation techniques that work across the signature formats GitHub accepts today, ECDSA, RSA, EdDSA, and S/MIME/CMS, meaning the vulnerability is broadly practical rather than theoretical.
Attackers Clone “Verified” GitHub Commits
For ECDSA, classical algebraic symmetry lets an attacker transform a valid signature pair (r,s) into an equally valid alternative (r, n‑s) using only public curve parameters; for OpenPGP RSA and EdDSA, the attack appends ignorable unhashed subpackets; for CMS/S/MIME the exploit leverages non‑canonical envelope encodings.
Crucially, GitHub’s server‑side verification accepts these mangled encodings and records each resulting commit as a distinct “Verified” object keyed by its hash, without signaling that two entries may represent byte‑different encodings of the same logical content.
Jacob Ginesin stated that the attack is not limited to single commits: because each commit embeds its parent hash, a malleated commit forces all descendants to be rewritten and rehashed to preserve a consistent chain, enabling an attacker to craft entire alternative histories that look valid and verified.
Proof‑of‑concept tooling automates detection of the signature type, applies the right malleation, rewrites descendant commits, and advances branch pointers so mirrors can serve these “ghost twin” revisions transparently.
For defenders, the consequences are immediate and troubling. Hash‑based blocking and incident response that blacklist specific SHA identifiers can be bypassed simply by re‑pushing a malleated twin under a fresh hash that is not on the block list.
Dependency‑pinning schemes that rely on commit SHAs, including Nix flakes, Go module pseudo‑versions, pinned GitHub Actions SHAs, and Dockerfiles referencing commit hashes, can be deceived by mirrors offering alternate yet validly signed histories.
Reproducible‑build and provenance frameworks such as SLSA and Sigstore implicitly trust commit hashes as immutable identifiers, but that assumption fails when signature malleability allows multiple distinct hashes to represent the same logical content.
Until platform and toolchain changes are broadly deployed, organizations should stop treating a “Verified” badge or a signed commit hash as a unique, immutable content identifier in high‑assurance contexts.
Practical mitigations include canonicalizing signatures and signed objects before computing or checking hashes, moving deduplication and blocking to post‑canonicalization artifacts, enforcing stricter canonical DER or container encodings at verification time, and augmenting audit trails to bind human and key identities to content beyond raw object bytes.
Security teams should also add tests that detect alternative encodings and refresh CI/CD gating logic to validate provenance after canonicalization; failing to adapt will leave supply‑chain, pinning, and reproducibility guarantees vulnerable to subtle but powerful hash‑chain forgeries.
No Comment! Be the first one.