From Recon to Letter of Recognition | NASA VDP

Full Source Code Disclosure from a “.git” Repository

Figure 1. Article banner

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

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.

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.

Figure 4. The website is pointing 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/"

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).

Figure 7. Accessing the exposed git configuration

6. The image below shows all of the 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

Figure 9. Build the Docker image

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.

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)

Figure 12. My NASA Letter of Recognition (LoR)

Thanks for reading, and happy hacking.✋😎🤚