Exposed .git Directory Leading to Source Code Disclosure and Hardcoded Credentials

Search for a command to run...

No comments yet. Be the first to comment.
Overview During a penetration test of a Web Applications API, I discovered a vulnerability in the password reset functionality that allowed an attacker to intercept reset tokens and take over user accounts. By manipulating a user-controllable field i...

Overview During a web application penetration test, I identified a broken access control issue that allowed a low-privileged user to escalate their privileges to administrator. The issue was easy to identify and had a high impact, as it allowed full ...

Overview During a black-box web application penetration test, I identified an unauthenticated SQL injection vulnerability that could be escalated to remote command execution. Although SQL injection vulnerabilities are less common today, this finding ...

Overview During a penetration test of a web application, I identified a flawed two-factor authentication implementation that could be bypassed using brute-force techniques. This finding demonstrates that poorly implemented two-factor authentication (...

Cyber Sekler
7 posts
During a web application assessment, I discovered an exposed .git directory that allowed me to download the application's entire source code. By extracting and analysing the git objects, I identified hardcoded credentials that granted admin-level access to the application.
The engagement was a black-box web application penetration test with the objective of testing and trying to bypass authentication to gain access to the application. Initial reconnaissance included directory enumeration to identify exposed files and directories.
While running directory enumeration with feroxbuster, I noticed the application returned a 200 response for /.git/. This indicated the git repository was publicly accessible.
I used git-dumper to download the exposed repository:
git-dumper https://target-redacted.com/.git/ ./output
This retrieved the git objects, but they were stored in compressed format. I wrote a quick bash script to decompress them:
#!/bin/bash
INPUT_DIR="objects"
OUTPUT_BASE="code"
count=1
for file in "$INPUT_DIR"/*; do
if [[ -f $file ]]; then
ruby -rzlib -e 'print Zlib::Inflate.new.inflate(STDIN.read)' < "$file" > "${OUTPUT_BASE}${count}"
((count++))
fi
done
echo "Processing completed."
With the objects now in clear text, I used gitleaks to scan for hardcoded secrets:
gitleaks detect --source='./output' --no-git -v
This returned results within seconds, identifying two hardcoded passwords in the source code.

The .git directory was accessible without authentication, exposing the full version control history including all source code files.
Using the discovered passwords with the username admin (an educated guess) granted administrative access to the application.
With access to the full source code, further analysis was possible using automated scanning tools to identify additional vulnerabilities without manually reviewing hundreds of files.
Exposed .git directories remain a common misconfiguration that can expose your entire codebase. Beyond the immediate risk of source code disclosure, developers often leave hardcoded credentials in code, turning a configuration issue into full application compromise.