CVE-2022-24975: Git-scm Git Information Disclosure Issue

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

bash

# 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