July 30, 2026

TryHackMe Room 404 Walkthrough: Exposed .git Directory Leads to Full Source Code Disclosure

Difficulty: Very Easy Category: Web Security / Information Disclosure / Version Control Misconfiguration

By iamrudhh

3 min read

Introduction

One of the easiest yet most impactful web security mistakes is exposing a Git repository to the public. A single accessible .git directory can allow attackers to reconstruct an application's entire source code, discover sensitive files, inspect commit history, and even recover secrets that developers thought had been deleted.

In this TryHackMe Hacker Holidays — Day 2: Room 404, we'll exploit an exposed .git directory, recover the application's source code, and find the hidden staging flag.

Although this room is beginner-friendly, the vulnerability is very real and has affected many production websites.

Room Overview

The Byte Lotus Guest Experience Platform was deployed in a hurry. During deployment, the developer accidentally left the Git repository inside the web root.

Objective

  • Discover the exposed Git repository
  • Recover the application's source code
  • Find the hidden staging flag

Target:

http://[MACHINE_IP]:8080

Step 1: Enumerate the Website

Whenever assessing a web application, directory enumeration should be one of the first steps. Hidden directories often expose backups, configuration files, development environments, or version control repositories.

We'll use dirsearch to look for common directories.

dirsearch -u http://[MACHINE_IP]:8080 \
-w /usr/share/wordlists/dirb/common.txt

After the scan completes, you'll notice something interesting.

/.git/HEAD (Status: 200)

Finding .git/HEAD with an HTTP 200 response immediately indicates that the Git metadata is publicly accessible.

This is a serious security issue because Git stores much more than source code.

Understanding the .git Directory

Every Git project contains a hidden .git folder that stores:

  • Complete commit history
  • Source code snapshots
  • Branch information
  • Tags
  • Object database
  • Developer metadata

Normally, this folder should never be accessible through a web server.

If it is exposed, an attacker can often reconstruct the complete repository.

Step 2: Verify the Repository

Open the following URL in your browser.

http://[MACHINE_IP]:8080/.git/HEAD

Response:

ref: refs/heads/main

Let's understand what this means.

Git ComponentDescriptionrefs/Stores Git referencesheads/Stores local branchesmainCurrent checked-out branch

The response confirms that this is a legitimate Git repository.

Step 3: Dump the Repository

Downloading hundreds of Git objects manually would be tedious.

Instead, we'll use git-dumper, which automates the entire process.

Create a Python virtual environment.

python3 -m venv venv

Activate it.

source venv/bin/activate

Install git-dumper.

pip install git-dumper

Now dump the repository.

git_dumper http://[MACHINE_IP]:8080/.git/ dumped_repo

Within a few moments, git-dumper reconstructs the project locally.

Step 4: Explore the Recovered Repository

Navigate into the recovered directory.

cd dumped_repo

List the contents.

ls -la

You'll now have access to the same files the developer used while building the application.

Depending on the project, you may find:

  • Source code
  • Configuration files
  • API keys
  • Environment variables
  • Database credentials
  • Documentation
  • Commit history

This demonstrates why exposing .git is considered a high-risk information disclosure vulnerability.

Step 5: Locate the Flag

Read the README file.

cat README.md

Output:

# Byte Lotus Guest Experience Platform
This is for the guest app and concierge personalization service.
Do not deploy this folder to production.
Staging flag (remove before launch):
THM{************************}

The staging flag is successfully recovered.

Why Is This Dangerous?

Many developers assume that deleting sensitive files removes them permanently.

Git doesn't work that way.

Git stores every committed version inside its object database.

If the .git directory is exposed, attackers can often recover:

  • Previous versions of files
  • Deleted credentials
  • API tokens
  • SSH keys
  • Database passwords
  • Internal documentation
  • Development notes

Even secrets removed months earlier may still exist inside Git history.

Real-World Impact

Exposed Git repositories have led to numerous security incidents.

Researchers frequently discover public websites exposing:

  • Cloud credentials
  • AWS keys
  • Internal source code
  • Customer data
  • Production configuration files

Attackers often automate searches for exposed .git directories because the reward is high and exploitation is straightforward.

How to Prevent This

Developers can prevent this issue by following a few simple practices.

Never Deploy the Entire Project Directory

Only deploy production-ready build artifacts.

Avoid copying the entire development folder directly to the web server.

Block Access to Hidden Files

Configure the web server to deny access to:

.git/
.svn/
.hg/
.env
.gitignore

Rotate Exposed Secrets

If credentials were ever committed to Git, assume they are compromised.

Rotate them immediately.

Add Deployment Validation

Automate deployment checks that fail if a .git directory exists inside the deployment package.

This simple validation prevents accidental exposure.

Key Takeaways

This room highlights a common but dangerous web security misconfiguration.

Always include version-control files during web enumeration.

Useful locations to check include:

/.git/
/.git/HEAD
/.svn/
/.hg/
/.env

A single accessible .git directory can expose an application's entire source code, commit history, and sensitive information.

Small misconfigurations often lead to significant security risks.

Conclusion

This TryHackMe room demonstrates how a seemingly harmless deployment mistake can expose an application's complete source code.

By combining simple directory enumeration with git-dumper, we reconstructed the repository and recovered the staging flag within minutes.

While the room is intentionally beginner-friendly, the underlying vulnerability is one that security professionals continue to encounter during real-world penetration tests and bug bounty engagements.

Always remember: a hidden folder is not a secure folder. If it's accessible over HTTP, it's exposed.

Happy Hacking! 🚀