This is Brijesh [Whiterose] here, and today's article is about how I uncovered a sensitive data exposure in NASA's EarthData that leaked internal developer details, PII — all without authentication.

Follow : Instagram Github Twitter

One day, while browsing Twitter, I saw a post from a cybersecurity researcher sharing an appreciation letter they got from NASA. The curious kid in me waked up, so I decided to check out NASA's Vulnerability Disclosure Program to see what kind of security testing they allowed.

To be honest i was not expecting what is going to be happened next !!

Recently, during one of my late-night recon sessions, my curiosity took me beyond Earth… literally. While mapping subdomains and public endpoints, I stumbled upon something inside NASA's EarthData. What I found? Let's just say it was a goldmine of developer information that could be very useful to the wrong person.

What's Sensitive Data Exposure & PII?

Sensitive Data Exposure happens when a system leaks private information without proper protection. If that information includes Personally Identifiable Information (PII) — like names, emails, Mobile number, Physical address or IDs — it can be used for phishing, social engineering, or even credential attacks.

In my NASA case, the API exposed full names, official NASA emails, commit messages, and project references — all without authentication. Even small leaks like this can give attackers the first foothold they need.

Now, I will explain the scenario in detail.

It all started with some reconnaissance on nasa.gov and its related assets. My plan was simple:

• Identify interesting subdomains.
• Look for exposed API endpoints.
• Test if they were leaking anything useful.

That's when I came across this endpoint:

https://xyz.nasa.gov/$$$/$$$/latest/$$$$/CMR/$$$$$/cmr-cloud-deployments/last-modified?at=$$$$$$$$$d251920784f6541c4da098967

It looked like a Bitbucket Server API (a system used for managing Git repositories). Normally, this type of endpoint should be behind authentication — but this one wasn't.

I opened my browser, pasted the URL, And blah blah blah… JSON data started flowing in.

What I saw made my eyebrows raise:

1. Full names of NASA developers.
2. Official NASA emails addresses
3. Mobile numbers
4. Physical address
5. Commit messages referencing internal projects and JIRA tickets
6. Timestamps of code changes
7. File names and IDs from internal repos

Why This Matters

In the security world, information is ammo. This data could be used for:

• Phishing — Send targeted emails to NASA devs.
• Reconnaissance — Learn about internal projects and workflows.
• Credential Stuffing — Try known password leaks against these emails.
• Attack Timing — Use timestamps to figure out deployment cycles.

It immediately caught my attention. I thought, "This could be sensitive. It's an audit report, and it's internal. Definitely something that shouldn't be out in the open." I decided to create a report and submitted it to Bugcrowd.

Within 15 hours, I got a message back from Bugcrowd. and the bug was triaged, and the vulnerability was accepted.

After 36 hours, they sent it to the NASA team to fix.

About a 10 Days later, I got the notification that the bug was resolved.

And after, I got Letter of Appreciation From NASA

Appreciation Letter

It was a pretty thrilling experience, and it all started from that simple curiosity about NASA and that Instagram post. It just goes to show how sometimes, a simple idea or a random thought can lead to discovering something significant.

Thanks for reading, and I hope you found my write-up informative.

Happy hunting, and remember to test responsibly!