Hacker Holidays 2026: Day 2 Walkthrough (Room 404)

This is Day 2 of my Hacker Holidays 2026 walkthrough series. Day 0 covered OSINT and hidden Instagram accounts. Day 1 demonstrated AI prompt injection against a concierge chatbot.

Today, we are back to classic web application hacking. And the vulnerability we are exploiting is one of the most common and most devastating misconfigurations that penetration testers find in the real world: an exposed .git directory on a production web server.

If you have not attempted this challenge yet, go try it first. Then come back.

The Setup

The challenge description sets the scene perfectly:

"The Byte Lotus guest-experience platform went live in a hurry, and the night-shift developer shipped more than the website."

That single sentence tells us everything we need to know. A developer deployed the application in a rush. When developers rush, they forget things. And the most dangerous thing a developer can forget to exclude from a deployment is the .git directory.

We are given a target IP and port. Time to investigate.

Step 1: Initial Reconnaissance

Navigating to the target in a browser reveals The Byte Lotus guest-experience platform. Exploring the site, we find a /bookings page. Nothing unusual on the surface.

But before poking at the frontend, let us check what the server is actually running. By inspecting the network calls in the browser's developer tools, the response headers reveal:

Server: Werkzeug/3.0.1 Python/3.12.3

Server: Werkzeug/3.0.1 Python/3.12.3

This tells us the backend is a Python web application running on Werkzeug, which is the WSGI utility library that powers Flask. This is useful context for understanding the technology stack.

Step 2: Directory Enumeration

Now we need to find what the developer accidentally left behind. We use dirsearch to brute-force directories and files on the web server:

dirsearch -u http://TARGET_IP:8080 -e php,txt,html,js

dirsearch -u http://TARGET_IP:8080 -e php,txt,html,js

The scan returns a critical finding: the server is exposing a /.git directory.

This is the jackpot.

Step 3: Understanding the Vulnerability

When developers use Git for version control (which is virtually every developer in 2026), a hidden .git directory is created in the project root. This directory contains everything: the complete commit history, configuration files, branch information, previous versions of every file and sometimes even secrets like API keys and credentials.

When a developer deploys the application to a web server by simply copying the entire project folder, the .git directory goes with it. If the web server is not explicitly configured to block access to dotfiles, anyone on the internet can browse to /.git and download the entire repository history.

This is not a theoretical vulnerability. It is found on production websites constantly. Bug bounty hunters report exposed .git directories regularly, and the impact ranges from source code disclosure to full credential leakage.

Step 4: Dumping the Git Repository

We cannot simply browse the .git directory in a browser and reconstruct the repository manually. We need a specialized tool.

Enter git-dumper, an excellent open-source tool designed specifically for this purpose. It recursively downloads all objects from an exposed .git directory and reconstructs a fully functional Git repository on your local machine.

First, clone and install the tool:

git clone https://github.com/arthaud/git-dumper
cd git-dumper
pip install -r requirements.txt

git clone https://github.com/arthaud/git-dumper
cd git-dumper
pip install -r requirements.txt

Then, point it at the target:

./git_dumper.py http://TARGET_IP:8080/.git ~/website

./git_dumper.py http://TARGET_IP:8080/.git ~/website

The tool downloads every Git object, reference and configuration file from the exposed directory. Within seconds, we have a complete local copy of the repository.

Step 5: Extract the Flag

The downloaded repository is stored in the ~/website folder. Navigating into it and examining the files, we find a README.md file that contains the flag:

THM{byt3_l0tus_n3v3r_f0rg3ts}

THM{byt3_l0tus_n3v3r_f0rg3ts}

Challenge complete.

What a Real Attacker Would Do Next

In a CTF, we grab the flag and move on. In a real-world penetration test, an exposed .git directory opens up a cascade of further exploitation:

Review the commit history. Running git log reveals every commit ever made. Developers frequently commit secrets (database passwords, API keys, AWS credentials) early in development and then "remove" them in a later commit. But Git remembers everything. Those secrets are still in the history.

git log --oneline
git diff HEAD~5

git log --oneline
git diff HEAD~5

Search for hardcoded credentials. Grepping the repository for common patterns can instantly reveal sensitive data:

grep -r "password" .
grep -r "api_key" .
grep -r "secret" .

grep -r "password" .
grep -r "api_key" .
grep -r "secret" .

Examine configuration files. Database connection strings, environment variables and internal service URLs are often stored in configuration files within the repository.

Check for other branches. Running git branch -a might reveal development or staging branches that contain experimental features with even weaker security controls.

How to Prevent This

If you are a developer or DevOps engineer, here is how to ensure this never happens on your deployments:

1. Never deploy by copying the project directory. Use proper deployment pipelines (CI/CD) that build clean artifacts without development files.

2. Configure your web server to block dotfiles. In Nginx, add this to your configuration:

location ~ /\. {
  deny all;
  return 404;
}

location ~ /\. {
  deny all;
  return 404;
}

In Apache, add this to your .htaccess:

RedirectMatch 404 /\.git

RedirectMatch 404 /\.git

Add .git to your .dockerignore and deployment exclusions. If you are using Docker, ensure the .git directory is explicitly excluded from the build context.

4. Scan your own deployments. Periodically check your production URLs by navigating to yourdomain.com/.git/HEAD. If it returns content instead of a 404 error, you have a problem.

The Answer

What is the flag?

THM{byt3_l0tus_n3v3r_f0rg3ts}

What is Next

Day 2 reminded us that the simplest misconfigurations often lead to the most devastating breaches. An exposed .git directory is not exotic or sophisticated. It is a deployment oversight that hands an attacker the keys to the kingdom.

Stay tuned for Day 3.

If this brought value then consider supporting or sponsoring. Follow the journey on X, Instagram ,Github or Youtube

Contents