Sitemap

Bug Bounty Guide: Finding and Exploiting Leaked .git/ Directories

7 min readJun 14, 2025

--

In this blog, we’ll look at how exposed .git/ directories can lead to critical information leaks. You’ll learn how to detect them, analyze their contents, and extract useful data during bug bounty or pentest engagements.

Press enter or click to view image in full size

Friend link: https://medusa0xf.medium.com/bug-bounty-guide-finding-and-exploiting-leaked-git-directories-1e05dc520bf5?sk=c74bf9252b3a4bbd84f3888b69e82a1f

The .git/ folder is the core of any Git project, it holds commit history, file contents, configuration, and even deleted data. When this directory is exposed due to a misconfiguration, it can leak the full source code, sensitive credentials, and internal logic. For bug bounty hunters, this kind of exposure can lead to serious $$$$ if exploited and reported right.

What is a .git/ directory?

.git/
├── config # Repo configuration
├── HEAD # Points to current branch
├── objects/ # All data objects (commits, files, dirs)
│ └── [sha1 split] # Stored using hashed names
├── refs/ # Branches and tags
└── index # Staging area

The .git/ directory is the core folder that Git uses to manage a project's entire version history. It contains all the metadata, commit history, and actual file contents tracked by Git.

Key Components Inside .git/

Here's a breakdown of the key components it stores and why each one matters during analysis or exploitation.

1. objects/ – Git’s Database of Everything

This folder stores all content and history in the form of Git objects: blobs (file contents), trees (directory structures), and commits (snapshots). Each object is saved using a SHA-1 hash and split into subdirectories to avoid overloading a single folder. If this directory is leaked, it’s possible to reconstruct the entire project, even deleted files.

.git/objects/
├── 7a/
│ └── 552eaf43fbfb05bfa5db4985040f68ae139a4b
├── c4/
│ └── e2dfaa1a6e3e1d3e02c3de34917f5801e8d6e6

2. refs/ – Pointers to Commits

Git uses this folder to store references such as branches and tags, which point to specific commit hashes. These help Git determine what the “main” branch is or where version tags point.

.git/refs/
├── heads/
│ └── main
├── tags/
│ └── v1.0

3. HEAD – The Currently Checked-Out Branch

This file tells Git which branch is currently active in the working directory. It usually points to a file inside refs/heads/, such as main or master.

# Contents of .git/HEAD
ref: refs/heads/main

4. config – Repository Configuration

This is the local Git config file for the specific repository. It stores settings like user identity, remote URLs, push/pull preferences, and more. These settings override the global .gitconfig.

[user]
name = example
email = dev@example.com
[remote "origin"]
url = https://github.com/user/repo.git

5. index – The Staging Area

Also known as the Git cache, this file tracks the state of files that have been staged using git add, but not yet committed. Git uses it to decide what goes into the next commit.

.git/index

6. logs/ – History of Git Actions

This folder contains logs of branch updates and checkouts. If a commit is accidentally deleted or a branch is messed up, these logs can help recover lost work.

.git/logs/
├── HEAD
└── refs/
└── heads/
└── main

Exploiting a Leaked .git/ Directory (Step-by-Step) Guide

Press enter or click to view image in full size
https://framerusercontent.com/images/dSmv61o9wUoOHuA7UG10kkimnQ.png

If the .git/ directory is left exposed on a web server, it's possible to reconstruct the site's source code and uncover sensitive information. Below is a clean breakdown of how to approach this.

Step 1: Check if the .git/ Directory is Accessible

First, test whether the .git/ directory is publicly accessible. A common way to do this is by checking if the .git/HEAD file returns a reference to a branch.

curl -I https://target.com/.git/HEAD

If the response includes something like ref: refs/heads/main, that means the Git metadata is exposed and further exploitation is possible.

Step 2: Manually Download Git Objects

Git stores its objects (commits, blobs, trees) using SHA-1 hashes, split into two parts: the first two characters are used as the folder name, and the rest is the file name inside that folder. You can recreate this structure locally and use curl to download the object.

mkdir -p .git/objects/7a/
curl https://target.com/.git/objects/7a/552eaf43fbfb05bfa5db4985040f68ae139a4b -o .git/objects/7a/552eaf43fbfb05bfa5db4985040f68ae139a4b

Make sure to replace the hash with a real one found from .git/HEAD, .git/refs/, or other files.

Step 3: Inspect the Object Using Git

Once the object is downloaded into the correct path, Git can be used to inspect it. Use git cat-file -p followed by the full hash to view its content. This helps identify whether it’s a commit, tree, or blob.

git cat-file -p 7a552eaf43fbfb05bfa5db4985040f68ae139a4b

A commit object will show metadata like author, date, and a pointer to a tree object.

Step 4: Explore the Tree to Find Files

A commit usually points to a tree object. That tree represents the folder structure and contains file names with their corresponding blob hashes. Use the tree hash from the previous step to list file entries.

git cat-file -p 463ab7c4b442d2856a9a07e73dd4d8f041e87661
Response:

100644 blob 9ddbdccfc128cb8fd14c1d13b3a4303bb1eaa4b0 index.php
100644 blob 68fb22f439999d373bddb5c873e9cf1d56b77723 config.php

These blob hashes are the actual file contents.

Step 5: Read the File Content from Blobs

Once you have the blob hash of a file, you can directly read its contents. This is where you start recovering source code and potentially sensitive data.

git cat-file -p 9ddbdccfc128cb8fd14c1d13b3a4303bb1eaa4b0

Repeat the process for each blob to recover important files like index.php, config.php, .env, and more.

What Kind of Sensitive Info Can Be Found?

Sure! Here’s your content rewritten in paragraph form for each point while keeping it chill and professional:

1. Configuration Files

Leaked Git directories often expose critical configuration files like .env, config.php, or settings.py. These files are goldmines as they tend to store environment-specific details such as database credentials, API keys, SMTP configurations, and secret tokens like JWT or OAuth keys. Access to any of these can give deep insights or even control over parts of the application.

.env
config.php
settings.py

2. Database Connection Strings

Another common find is database connection strings. These are usually located inside the environment or config files and contain the host, username, and password needed to access the database. If these credentials are for a production server, it could allow unauthorized access to sensitive data, user info, or even let someone drop the entire DB.

DB_HOST=localhost  
DB_USER=root
DB_PASS=toor123

3. API Keys & Third-Party Tokens

You might also stumble upon hardcoded API keys for services like Stripe, Firebase, AWS, or Twilio. These keys are sometimes left inside source files or config files and can be abused to make payments, send messages, access storage buckets, or spin up cloud instances, depending on the level of permissions.

STRIPE_SECRET_KEY=sk_live_...  
AWS_SECRET_ACCESS_KEY=AKIA...

4. Hardcoded Credentials

Developers sometimes hardcode test usernames and passwords into the code while debugging or during early development. These often slip through commits and remain buried in history, even if removed later. If found, they can be used to access admin dashboards, staging servers, or even SSH/FTP interfaces in some cases.

$username = 'admin';  
$password = 'admin123';

5. Deleted Files That Were Committed Earlier

One of the more powerful aspects of Git is version control, which means even deleted files are still accessible in the commit history. By checking out older commits, you can often recover files that contain sensitive info like backup scripts, dev notes, or vulnerable code that was removed later. This can expose business logic flaws, secrets, or old bugs.

git log  
git checkout [old-commit]

Tools for Git Recon

If a site has an exposed .git/ folder, these tools can help dig into it, from spotting the leak to grabbing the full source and juicy secrets hidden inside.

1. GitTools - Auto Recon & Dump

GitTools is a collection of scripts to help download and reconstruct Git repositories from public .git/ folders. It’s a go-to in CTFs and real targets.

2. Gitleaks - Secret Detection in Git History

Gitleaks scans Git repositories for hardcoded secrets. It’s great when you’ve already dumped a repo and want to spot secrets fast.

It checks the entire Git history and flags things like AWS keys, JWT secrets, or basic auth credentials.

3. GitDumper: Download Exposed .git/ Repositories

When a .git/ directory is publicly accessible, and manually reconstructing the repo by downloading object files one by one can be slow and tedious. That’s where GitDumper comes in, it automates the entire process.

This tool crawls the exposed .git/ directory, identifies and downloads Git object files, and attempts to reconstruct the full repository locally.

Reports for reference:

For further reading, check out these reports:

Final Thoughts

Leaked .git directories can expose sensitive information like source code, configuration files, and credentials. Understanding how to detect and analyze them is a valuable skill for any bug bounty hunter or security professional.

Keep practicing, stay curious, and always dig deeper during recon!

--

--