# GitHub's Verified Commits Can Be Rewritten—Undermining Git's Core Security Promise


A critical gap in GitHub's commit verification system allows attackers to rewrite repository commits while preserving digital signatures, defeating one of Git's most important trust mechanisms and creating a sophisticated supply chain attack vector that most developers may not realize exists.


Researchers have discovered that GitHub's "verified" commit badge—the checkmark that assures users a commit was cryptographically signed by a known developer—does not actually prevent commit manipulation. By exploiting how Git handles commit metadata and signature validation, attackers can modify commits, reassign authorship, or insert malicious code while keeping signatures intact, making tampering virtually undetectable to anyone relying on GitHub's verification UI.


## The Threat: False Assurance at Scale


The vulnerability exposes a fundamental mismatch between what developers believe they're verifying and what is actually protected. When a developer sees a green "Verified" badge on a commit, they typically assume:


  • The code hasn't been modified since signing
  • The author is who the commit claims to be
  • The repository history is tamper-evident

    • None of these assumptions are guaranteed.


    An attacker with access to a repository (or through a compromised account, insider threat, or repository takeover) can:

  • Rewrite older commits while keeping signatures intact
  • Modify commit messages or metadata
  • Alter file contents without breaking signature validation
  • Make tampering invisible in GitHub's interface

    • This is particularly dangerous because:

  • Supply chain attacks: Open-source maintainers are high-value targets. Rewriting a signed commit in a widely-used library could inject malware into thousands of projects
  • Regulatory bypass: Organizations relying on signed commits for compliance (SOC 2, ISO 27001) may unknowingly accept tampered code
  • Trust inversion: Signatures create a false sense of security, potentially causing developers to skip additional code review or security checks

    • ## Technical Details: How Commit Malleability Works


    Git's security model relies on content-addressable storage—each commit's hash is derived from its entire content tree, parent references, author metadata, and timestamp. Changing any bit should invalidate the hash entirely.


    However, the vulnerability exploits a gap in how signatures are validated against commits:


    1. Signature placement: Git signatures (typically using GPG, SSH, or S/MIME) sign the commit object. But the commit object's structure includes fields that *can* be modified in certain contexts while the signature technically remains valid.


    2. Rebase and rewrite operations: Git allows developers to rebase, amend, and rewrite history locally. When these changes are pushed, GitHub typically allows force-pushes if the pusher has write access. The question: does the signature remain valid if the commit content changes?


    3. Verification gap: GitHub's verification system checks whether a signature *exists and is cryptographically valid*—but under certain conditions, a rewritten commit can retain a valid signature because the cryptographic signature was computed over data that doesn't uniquely identify the final commit.


    This is a subtle but catastrophic difference. A valid signature should guarantee immutability; instead, it only guarantees the signature came from someone holding the private key—not that the commit hasn't been altered since.


    ## Background and Context: Git Verification Has Always Been Optional


    For years, Git commit signing remained optional and rarely enforced. GitHub introduced the "Verified" badge in 2013, giving developers a visual way to assert commit authenticity. However, signing only protects against certain attack vectors—specifically, it prevents someone *without your private key* from forging your identity.


    It does not prevent:

  • You or an attacker with your credentials from rewriting history
  • Repository administrators from altering commits
  • Weak implementations from being exploited

    • Recent industry momentum toward supply chain security (Secure Supply Chain Framework, SLSA, Software Bill of Materials) has increased reliance on commit signatures as a proxy for code authenticity. Organizations are increasingly *requiring* signed commits. This research demonstrates that requirement provides less protection than assumed.


    ## Implications: Who Should Panic?


    Immediately vulnerable:

  • Open-source projects that rely on signed commits as their primary anti-tampering control
  • Enterprise development teams with policies requiring commit signatures but no secondary verification
  • CI/CD pipelines that automatically merge or deploy commits tagged as "verified"
  • Compliance programs treating signed commits as sufficient evidence of code integrity

    • Secondary risk:

  • Any downstream consumer of code from these sources
  • Organizations using commit signatures to meet regulatory audits without understanding the limitations

    • ## Recommendations: Hardening Your Defense


    Until GitHub and Git tooling address this comprehensively, defenders should:


    ### For Repository Maintainers

  • Don't rely solely on signatures: Require code review and approval workflows *in addition* to signed commits
  • Use branch protection rules: Enforce that signed commits alone don't bypass review, approval, or CI checks
  • Audit commit history regularly: Use git log --show-signature to verify expected commits and watch for unexpected rewrites
  • Implement push restrictions: Limit who can force-push to main branches; treat force-push as an exceptional, logged event

    • ### For Organizations

  • Deploy secondary verification: Use signed tags or release checksums in addition to commit signatures
  • Audit trailing: Log and alert on history rewrites, forced pushes, and administrative actions
  • Strengthen access controls: Minimize who holds write access to critical repositories; use temporary credentials with short expiration
  • Treat signatures as a data point, not proof: Signed commits should complement, not replace, code review, SBOM generation, and integrity verification

    • ### For Developers

  • Understand what signatures protect: They prove you had the private key; they don't prove no one else rewrote the commit
  • Review CI/CD logs: Verify that builds actually ran against the commit code you expect
  • Stay current on tooling: Watch for patched versions of Git and GitHub that address this gap

    • ## HackWire Analysis


    This vulnerability exemplifies a critical pattern in security: the trust-UI gap. GitHub's "Verified" badge creates a psychological security boundary that the technical implementation doesn't actually enforce. Users see green ✓ and assume immutability; the system only guarantees a cryptographic proof of identity under narrow conditions.


    What makes this particularly consequential is timing and adoption. As organizations hardened by recent breaches and compliance mandates move toward "shift-left" security practices, they're increasingly automating approvals based on commit signatures. A CI/CD pipeline that auto-merges or auto-deploys "verified" commits is now a plausible attack scenario—not hypothetical. An insider, a supply-chain compromise, or account takeover becomes a supply-chain attack vector.


    The pattern mirrors prior Git surprises: Git's flexibility and permissive rewrite semantics (designed for local work) collide with remote repository assumptions (where rewrite = tampering). GitHub has excellent access controls, but they don't protect against misuse of legitimate credentials. The real mitigation isn't technical patching alone—it's process discipline. Require approval *after* signature verification. Log and alert on rewrites. Audit repository history like you'd audit file integrity.


    The broader lesson: Trust UI is not trust architecture. A green badge is a hint, not a guarantee. For supply chain security, assume signatures are necessary but not sufficient. — *HackWire Editorial*


    ## Related Coverage


  • Read more in our [Tools](https://www.hackwire.news/category/tools) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)