CVE-2022-24975 Overview
CVE-2022-24975, known as "GitBleed," is an information disclosure vulnerability affecting Git through version 2.35.1. The vulnerability relates to the --mirror documentation for Git, which does not adequately mention the availability of deleted content when performing clone operations. This documentation gap could present a security risk if information-disclosure auditing processes rely on a standard clone operation without the --mirror option, potentially leaving sensitive deleted content accessible to attackers who perform a full mirror clone.
It is important to note that this CVE has been disputed by multiple third parties who believe this behavior is an intended feature of the Git binary and does not constitute a security risk. However, organizations relying on Git for version control of sensitive data should be aware of the implications.
Critical Impact
Sensitive information previously committed and then deleted from Git repositories may remain accessible through mirror clones, potentially exposing credentials, API keys, configuration secrets, and other confidential data that developers believed was removed.
Affected Products
- Git versions through 2.35.1
- Git-scm Git (all versions prior to documentation clarification)
- Any systems performing security audits using standard git clone without --mirror
Discovery Timeline
- 2022-02-11 - CVE-2022-24975 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2022-24975
Vulnerability Analysis
The GitBleed vulnerability stems from a documentation gap in Git's --mirror option behavior. When developers or security teams perform a standard git clone operation, they receive only the current state of branches and tags. However, Git repositories internally retain objects that may no longer be reachable through normal references, including content that was "deleted" through force pushes, branch deletions, or history rewrites.
When using the --mirror flag, Git performs a bare clone that includes all refs and the complete object database, including unreachable objects. This means that sensitive data such as hardcoded credentials, API keys, private certificates, or other secrets that were previously committed and then "deleted" through git rebase, git filter-branch, or similar history-rewriting operations may still be accessible.
The core issue is that security auditing processes and compliance checks that rely on standard clone operations may falsely conclude that sensitive data has been successfully removed from a repository when it actually persists in the Git object database.
Root Cause
The root cause is classified under CWE-668 (Exposure of Resource to Wrong Sphere). The vulnerability exists because Git's documentation for the --mirror option did not clearly communicate that deleted content remains available through mirror clones. This documentation gap leads to a false sense of security when organizations attempt to remove sensitive data from repositories.
Git's architecture stores all objects (commits, trees, blobs) in an object database. Even when objects become unreachable through normal references, they persist until garbage collection actively removes them. Mirror clones capture this complete state, including "deleted" content that standard clones would not retrieve.
Attack Vector
An attacker exploiting this vulnerability would perform a mirror clone of a target repository to access deleted content. The attack is network-based and requires no authentication beyond what is needed to access the repository itself. The attack can be executed as follows:
- Attacker identifies a Git repository of interest (public or one they have access to)
- Attacker performs a git clone --mirror operation instead of a standard clone
- Attacker examines the complete object database for unreachable objects
- Attacker extracts sensitive data from objects that were "deleted" from the repository history
This attack is particularly effective against repositories where developers have previously committed secrets (such as API keys, database credentials, or private keys) and then attempted to remove them through history rewriting. The Nightwatch Cybersecurity GitBleed Analysis provides detailed information on this attack methodology. Additional research from AquaSec on Hard-Coded Secrets explores the broader implications of exposed secrets in version control systems.
Detection Methods for CVE-2022-24975
Indicators of Compromise
- Unusual git clone --mirror operations against repositories containing sensitive data
- Access logs showing complete repository database transfers rather than standard branch clones
- Evidence of secret extraction tools being used against cloned repositories
- Unexpected authentication using credentials that were supposedly removed from repositories
Detection Strategies
- Monitor repository access logs for --mirror clone operations, particularly from unexpected sources
- Implement secret scanning on all repository objects, not just current branch heads
- Use Git hosting platform audit logs to track full repository clones versus partial clones
- Deploy secret detection tools that analyze the complete Git object database
Monitoring Recommendations
- Enable comprehensive audit logging on Git hosting platforms (GitHub, GitLab, Bitbucket)
- Implement alerts for bulk repository cloning activities
- Regularly scan repositories for exposed secrets using tools like git-secrets, truffleHog, or Gitleaks
- Monitor for credential usage that correlates with recently "deleted" secrets
How to Mitigate CVE-2022-24975
Immediate Actions Required
- Audit all repositories for previously committed secrets, scanning the complete object database including unreachable objects
- Rotate any credentials, API keys, or secrets that have ever been committed to repositories, regardless of deletion status
- Implement pre-commit hooks to prevent secrets from being committed in the first place
- Review repository access controls to limit who can perform mirror clones
Patch Information
This issue is primarily a documentation concern rather than a code vulnerability. The Git Documentation Reference provides the official documentation for the --mirror option. Organizations should focus on operational mitigations rather than waiting for a specific patch. The Git maintainers have discussed this issue on the Kernel Lore mailing list.
Workarounds
- Use git gc --prune=now on repositories after removing sensitive data to garbage collect unreachable objects
- Consider using BFG Repo-Cleaner or git filter-repo for thorough history sanitization
- Implement repository policies requiring server-side garbage collection after secret removal
- For highly sensitive repositories, consider recreating repositories from scratch rather than attempting to purge history
# Configuration example for repository cleanup after secret removal
# Run garbage collection to remove unreachable objects
git reflog expire --expire=now --all
git gc --prune=now --aggressive
# Verify no sensitive objects remain
git fsck --unreachable | wc -l
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
