GitHacker

An Empirical Study of .git Leakage Exploitation

Wang Yihang  ·  benchmark updated May 27, 2026  ·  commit 2ad0244

Abstract

When a web server inadvertently exposes its .git directory, the entire repository — including its source code, commit history, branches, and stashes — becomes reconstructible by anyone with HTTP access. We benchmark seven open-source pillagers across five server configurations and fifteen adversarial scenarios, and find that completeness varies by more than 60 percentage points across tools, that the most aggressive tool issues ten times more HTTP requests than the most efficient one, and that every pillager except GitHacker currently fails at least one published code-execution test against a malicious .git. We publish a reproducible benchmark, full per-scenario data, and a coordinated-disclosure tracker for unresolved findings.

§1. Introduction

A leaked .git directory is the most concentrated form of source-code disclosure a web target can suffer: a single misconfiguration exposes commit history, deleted branches, abandoned stashes, and any credentials a developer once committed in error. Despite a decade of off-the-shelf exploitation tools, no two pillagers behave identically — one will brute-force tag names that another silently skips, one will follow a malicious redirect into the attacker's filesystem while another refuses. This site reports a side-by-side measurement.

§2. Summary of Findings

Three findings emerge from our measurement; each links to the underlying data:

  1. Completeness varies by 60+ points. Mean recovery rate across the five web-server scenarios ranges from below 30% (legacy single-threaded tools) to above 95% (GitHacker, git-dumper). See Benchmark §3.
  2. HTTP cost is not free. The most aggressive tool issues an order of magnitude more requests for an equal-or-worse recovery. Quiet, targeted brute-force matters. See Benchmark §5.
  3. Every tool except GitHacker fails at least one adversarial test. Six of seven pillagers are vulnerable to core.fsmonitor code execution from a malicious .git/config; SSRF and arbitrary-file-write findings remain under embargo pending upstream patches. See Security.
0 25 50 75 100 GitHacker 99.2% git-dumper 78.8% git-hacker (rbozburun) 78.8% dumpall 32.0% GitHack 32.0% GitTools 0.2% dvcs-ripper 0.0%
Figure 1. Mean completeness ratio per tool, averaged across five web-server scenarios (Apache / Nginx, directory-index on / off, PHP-LFI). GitHacker shown in accent; bars sorted descending.

§3. Reproduce

The entire benchmark — server containers, tool containers, test repository generator, scoring harness — runs from a single Docker invocation:

docker run wangyihang/githacker:benchmark python -m benchmark run

Full instructions ›

§4. Related Work

Justin Steven's 2022 advisory documents the original core.fsmonitor RCE in .git/config; Driver Tom's 2021 blog post catalogued generic counter-attacks against source-code pillagers; Git's own security advisory feed lists more than a dozen CVEs reachable via git clone of a hostile repository.

  1. justinsteven. Various abuses of core.fsmonitor in a directory's .git/config. 2022. github.com/justinsteven/advisories
  2. Driver Tom. 别想偷我源码：通用的针对源码泄露利用程序的反制. 2021. drivertom.blogspot.com
  3. Git project. Security advisories. github.com/git/git/security/advisories

Citation

@misc{githacker2026,
  author       = {Wang, Yihang},
  title        = {GitHacker: An Empirical Study of .git Leakage Exploitation},
  year         = {2026},
  howpublished = {\url{https://githacker.pages.dev}},
  note         = {Benchmark commit 2ad0244, seed 0}
}