Full Source Code Disclosure from a ".git" Repository

Hola Hacker's

In this article, I will explain a full walkthrough of how I got a Letter of Recognition (LoR) from the NASA Vulnerability Disclosure Program (VDP) on the BugCrowd platform. The source code disclosure I found should be rated P3 according to the Vulnerability Rating Taxonomy (VRT) on the BugCrowd platform. But, at first, the BugCrowd team marked this finding as "Not Reproducible". But, in the end, the NASA team decided to change this finding to P3 again and successfully resolved this issue.

⚠️ Disclaimer This article is written purely for educational purposes. I am not responsible for any misuse or illegal activity conducted with this knowledge. Only practice on systems you own or have explicit permission to test.

Key Timeline

  1. April 02, 2026: Submit report, and the BugCrowd team changed the state to "Not Reproducible."
  2. April 24, 2026: NASA Team process to fix the issue
  3. April 27, 2026: The NASA Team fixed the issue and changed the state to "Resolved."

Background

Many people who get into a bug bounty job say, "Recon is the key." Now, I realize why it's so important, even if it takes more than 1 day. All you need is just focus, sit, and relax, waiting until the recon phases are completed. One more thing that you may consider is "attention to any details (including each path)" that potentially could be findings.

Step to Reproduce

1.) I started by looking for a PHP page on any NASA subdomain using a Google Dork. I use this simple Google Dork payload.

site:*.nasa.gov extension:php
site:*.globe.gov extension:php
NASA website target
Figure 2. NASA target website

2) Then I started analyzing this NASA website: "https://fermi.gsfc.nasa.gov/redacted/". Based on the previous Google Dork results, I'm looking for any page with a .php extension.

None
Figure 3. NASA target website overview

3) When I open the same page on that website and also open the console tab, I found that the page is pointing to the queryDB.php (back-end file) with some parameters to fetch data. It's looking suspicious to me, so I try to access that page, including the parameters.

The website is pointing suspicious file
Figure 4. The website is pointing suspicious file
Accessing the suspicious file
Figure 5. Accessing the suspicious file

4) I tried exploiting potential vulnerabilities across all parameters, such as SQL injection, XSS, SSTI, and LFI, but had zero luck. In that situation, I was thinking, "What if I scan the page using Nuclei?" Maybe there's a hidden directory that was accidentally exposed or another security misconfiguration. Here's the nuclei command that I used to scan the page.

nuclei -target "https://fermi.gsfc.nasa.gov/redacted/"
Scanning the website page to find some security issues
Figure 6. Scanning the website page to find some security issues

5) As you can see in the image above, the nuclei scan results show something interesting, which is an exposed .git repository. From this scenario, I immediately cloned the source code repository (which has now been closed and fixed by the NASA team).

Accessing the exposed git configuration
Figure 7. Accessing the exposed git configuration

6) The image below shows all of the source code disclosure.

List of all source code disclosure
Figure 8. List of all source code disclosure

7) As you can see in the image above, there's a queryDB.php file that was previously found. There are some database files, but no credential exposures that can be exploited. But, to make this a valid finding, I try to deploy the website locally using Docker. All we need is a Dockerfile and use this command to build.

# command to build
docker build -t nasa-xxx:latest .

# check all Docker images
docker images

# run the Docker container
docker run -d -p 80:80 -p 443:443 --name "nasa-xxx" --hostname "nasa-xxx" nasa-xxx:latest
Build the Docker image
Figure 9. Build the Docker image
Running the Docker container
Figure 10. Running the Docker container

8) As shown in the image above, I can create a Docker image and run a container. This is the website if I'm running locally.

Accessing the website target locally after running the Docker container
Figure 11. Accessing the website target locally after running the Docker container

Remediation

Before deploying the source code to any cloud repository platform, such as GitHub, GitLab, or Bitbucket, ensure the .gitignore file exists and is properly configured. Another way to do that is to run a vulnerability scan with Nuclei or other tools to identify potential system risks. It's recommended to deploy to the staging/development server first, before finally going up to the production server.

Lesson Learn

This is my first time participating in a bug bounty program, and I have zero expectation that this finding could be a valid report. It's proof of it, because after I submitted the report and the BugCrowd team marked this finding as "Not Reproducible". I'm not giving up yet, I continued hunting in NASA VDP and looking for another possible vulnerability. The next day, I found PII data leakage and broken-link hijacking vulnerabilities; the BugCrowd team marked those findings as P5 (Informational). However, those 2 findings have not yet been reviewed or resolved by the NASA team, so I decided to keep hunting. After 1 month of waiting, the NASA team decided to change this finding to P3 again and said they will proceed with this issue. I'm happy to see that, and 2 days after this issue was resolved, I got LoR from the NASA team. Although I was waiting for a long time (1 month), in the end, all of my hard work finally paid off. So, you need to always think positively, be patient, and look for any chaining that could potentially improve your finding rating (P1-P4 to get the LoR).

My Letter of Recognition (LoR)

My NASA Letter of Recognition (LoR)
Figure 12. My NASA Letter of Recognition (LoR)

Thanks for reading, and happy hacking.✋😎🤚