01
Background & Motivation
Finding a vulnerability on NASA's infrastructure wasn't a goal I set out with — it happened through methodical recon. I was working through Bugcrowd's Vulnerability Disclosure Program, exploring *.nasa.gov subdomains as part of a broader research session. What started as routine enumeration turned into one of the most impactful findings of my career so far.
Context
NASA participates in a public Vulnerability Disclosure Program (VDP) hosted on Bugcrowd. VDPs don't pay monetary bounties, but they're some of the most meaningful targets you can responsibly research — real infrastructure, real stakes, and real impact when something is fixed. NASA also issues Letters of Recognition (LOR) for significant findings, which are highly valued in the security community.
02
Reconnaissance — Subdomain Enumeration
My first step was subdomain enumeration using Subfinder — a fast passive subdomain discovery tool. NASA's attack surface is enormous, with hundreds of active subdomains, so the goal was to identify outliers that might have different security postures from the main domains.
Bash · Subfinder
# Passive subdomain enumeration against NASA's domain subfinder -d nasa.gov -o nasa_subs.txt # Check for directory listing / open endpoints cat nasa_subs.txt | httpx -status-code -title -tech-detect
Going through the discovered subdomains manually — a process that's tedious but often rewarding — I spotted one subdomain that behaved differently. Instead of the polished NASA web experience, it returned something unexpected: a directory listing.
03
The Discovery — Directory Listing & Exposed Admin
Directory Listing Enabled
Accessing the site's root directory exposed its full file structure publicly — no authentication required. This is a classic misconfiguration where the web server is not configured to hide directory indexes, effectively handing an attacker a map of the application.
The endpoint that caught my attention immediately was:
Discovered Endpoints
# Directory listing — exposed file structure https://redacted.nasa.gov/site/ → 200 OK (directory listing enabled) # Admin login panel found inside directory listing https://redacted.nasa.gov/cgi-bin/site/admin/admin → Login page
Inside the directory listing, I could see not just the file structure but also admin usernames exposed in configuration or log files. These usernames gave me a starting point. The admin panel itself was a standard CGI-based login form — old-school, but fully functional.
04
Exploitation — Credential Guessing & Admin Takeover
With the exposed usernames in hand, I tried a simple but effective approach: username + number combinations as credentials. No heavy tooling, no bruteforce — just logical prediction based on common weak credential patterns that administrators often set on internal or legacy systems.
Access Granted
One of the credential combinations matched. I was now authenticated as an admin user on an official NASA subdomain. The login required no MFA, no CAPTCHA, and had no rate limiting — a trifecta of authentication failures that made this possible with minimal effort.
Login Attempt Pattern
# Username leaked via directory listing username = [exposed_admin_name] # Password pattern tested: username + number password = [username]1 → ✗ Fail password = [username]12 → ✗ Fail password = [username]123 → ✓ SUCCESS — Admin access granted
P1
Critical Severity
100%
Site Control
NASA
Gov Target
05
Proving Full Impact — Beyond Initial Report
After gaining access, I submitted the report to NASA via Bugcrowd. The initial response was discouraging — the report was triaged as Informational – Not an Issue. The severity was clearly being underestimated, so I went back to demonstrate the real-world impact of the compromised admin panel.
Initial Report Dismissed
The first submission was marked Informational – Not an Issue. This is a common frustration in bug bounty — triagers sometimes underestimate access-control bugs without proof of exploitable impact. The solution: demonstrate exactly what a malicious actor could do with the access.
Through the admin panel, I was able to perform the following actions — all documented with screenshots for the resubmission:
Upload HTML & Payloads — Files including HTML and RCE payloads could be uploaded directly via the panel
Create Posts & Blogs — Publish arbitrary content to an official NASA subdomain
Delete Content — Remove existing pages and published material from the site
Full Site Management — Complete control over all CMS features — posts, media, settings, users
Site Defacement / Takedown — Potential to deface or fully take down the subdomain
Edit Existing Content — Modify any published page, inject scripts, or tamper with official NASA content
NASA Recognition
Letter of Appreciation Awarded ✓
After the resubmission with full proof-of-concept screenshots demonstrating content creation, deletion, and upload capabilities, the report was re-evaluated and accepted as P1 (Critical). NASA issued a formal Letter of Appreciation (LOR) acknowledging the responsible disclosure. While there was no monetary bounty — this is a VDP — the LOR is a meaningful recognition from a US government space agency, and something that carries real weight in a security portfolio.
06
Step-by-Step Walkthrough
1
Subdomain Enumeration with Subfinder
Ran Subfinder against nasa.gov to passively collect all known subdomains. Output was piped through httpx to filter for live hosts and detect technologies. Manually reviewed the results for anomalies.
2
Identified Directory Listing on Target Subdomain
One subdomain returned a full directory listing at
/site/. This exposed the file structure of the application — including configuration files, logs, and path references that revealed admin usernames.3
Located Admin Login Panel via Directory
Within the exposed directory, identified the path
/cgi-bin/site/admin/admin — a CGI-based admin interface. No authentication was needed to reach the login page itself.4
Extracted Admin Usernames from Directory
Reviewed files accessible through the directory listing and identified admin usernames that had been inadvertently exposed. These became the basis for the credential guessing attempt.
5
Credential Guessing — username + number pattern
Attempted simple credential combinations using the known username plus common numeric suffixes (1, 12, 123, etc.). No rate limiting or lockout was in place. One combination succeeded — full admin access was granted immediately.
6
Initial Report Submitted — Dismissed as Informational
Reported the finding to NASA via Bugcrowd with details of the access. The initial triage marked it as Informational – Not an Issue, likely due to insufficient demonstration of exploitability. Rather than accepting this, I went back to prove the real impact.
7
Demonstrated Full Exploitation with Screenshots
Used the admin panel to upload files, create and edit posts, delete content, and demonstrate full CMS control. Documented each action with timestamped screenshots showing the capability to fully manage or deface the site.
8
Resubmission → Accepted as P1 Critical + LOR Issued
Resubmitted the report with the full proof-of-concept. The finding was re-triaged as P1 (Critical). NASA confirmed the issue, remediated it, and issued a formal Letter of Appreciation recognizing the responsible disclosure.
07
Disclosure Timeline
Phase 1
Recon — Subdomain Enumeration
Ran Subfinder against nasa.gov. Identified a subdomain with anomalous behavior — directory listing enabled at
/site/.Phase 2
Vulnerability Discovered
Directory listing revealed admin usernames and the CGI admin login path. Attempted credential guessing — successfully authenticated into the admin panel.
Phase 3
Initial Report — Dismissed as Informational
First submission to NASA via Bugcrowd. Triaged as "Informational – Not an Issue." The severity and impact were not sufficiently conveyed in the initial report.
Phase 4
Deeper Exploitation — Proof of Full Impact
Returned to the admin panel and demonstrated content upload, creation, editing, and deletion. Captured screenshots of each capability as evidence for resubmission.
Phase 5
Resubmitted → Accepted as P1 Critical ✓
Report resubmitted with full proof-of-concept and screenshots. Accepted as P1 (Critical). Vulnerability remediated by NASA. Formal Letter of Appreciation issued. 🎉
08
Key Takeaways
Subdomain enumeration pays off. The main nasa.gov domain was hardened, but a legacy subdomain had a completely different security posture. Always enumerate — large organizations have sprawling attack surfaces.
Directory listing is never just "informational." An enabled directory listing can expose usernames, file paths, config files, and internal structure — all of which compound into much larger vulnerabilities, as shown here.
Weak credentials are still everywhere. Username + sequential number is a pattern that still works on legacy admin interfaces, especially internal or low-priority systems that were never security-reviewed.
Don't accept "Informational" without a fight. If you know the impact is real, prove it. Go back, demonstrate the actual exploitability with evidence, and resubmit. The severity upgrade from Informational to P1 Critical is the difference between being ignored and being recognized.
Screenshots and PoC are everything. A report without proof is just a claim. Document every step, every capability demonstrated, and every screenshot. Triagers need to see the impact, not just imagine it.
Final Thought
This finding started with a routine Subfinder run and ended with a P1 Critical on NASA and a Letter of Appreciation. The vulnerability itself — directory listing exposing usernames, weak credentials on an unguarded admin panel — is a chain of small misconfigurations that adds up to total site control. The lesson isn't just technical. It's about persistence: when your first report is dismissed, gather more evidence and resubmit. Hack ethically. Document everything. Disclose responsibly. Never give up on a legitimate finding.