My first HackerOne report landed as a HIGH-severity information disclosure on a major education platform. Here's exactly what I found, how I found it, and what it means if you're shipping AI to production.
On June 29, 2026, I submitted my first HackerOne vulnerability disclosure report — and it landed in triage as severity HIGH (7-8.9) against Khan Academy's public VDP program.
The vulnerability class? Information disclosure via a feature flag leakage. The kind of thing that tells an attacker exactly which AI features are live on production — and which are in the canary bucket ready to be enabled with a single config change.
This post is the full breakdown: methodology, the recon chain, the exact bug, and 7 other findings I bundled into the same report.
Public AI security bug bounty is different from traditional security research. You're not breaking in — you're finding what the company accidentally leaked about their AI stack. The best AI security researchers I know spend 70% of their time on passive reconnaissance, and that's the lesson here.
I started with a passive scan. No clicks, no probes, no Nikto. Just DNS:
# Find subdomains fast (no detection)
subfinder -d khanacademy.org -silent -o subs.txt
# Result: 144 subdomainsSubfinder uses Certificate Transparency logs, DNS datasets, and search engines. It's all public data — the target never sees you.
# Which are actually serving HTTP?
cat subs.txt | httpx -status-code -title -tech-detect -silent
# Result: 100+ hosts respondingThis is where most people stop. They have hundreds of URLs. They click around until they find something interesting.
I don't. I move to step 3.
The thing nobody tells you about AI security research: the bugs aren't subtle. Once you've seen 10 AI agents deployed by 10 different companies, you start to recognize the same architectural patterns. And patterns leak metadata.
Here's the pattern I look for in every AI-enabled site:
Does the site load any JavaScript that references model identifiers, version flags, deployment canary deployments, A/B test buckets, or feature flags? If yes — that's the entry point.
Khan Academy's frontend loaded JavaScript with a feature flag initialization table. And one of those flags was set to true for an internal beta cohort.
Khan Academy's main web app uses LaunchDarkly (or similar) for feature flagging. The flag initialization payload is loaded on every page render. The payload includes all flags, including ones the user shouldn't have visibility into.
One of those flags was named ai-tutor-feature-enabled (details redacted per coordinated disclosure). The flag value was false for me — but the flag's existence told me two critical things:
That let me design a targeted attack. If I could find the cohort identifier (which came from a separate subdomain's analytics payload), I could self-select into the experimental AI tutor — bypassing whatever guardrails were being tested.
CVSS 7.0 - 8.9 because:
The principle: a feature flag isn't just a config. It's a map of what's coming next, and once an attacker has that map, the rest is game theory.
If you've shipped an AI agent in the last 18 months, you almost certainly have this. The pattern is universal: frontend frameworks load initialization payloads before the user's session is even validated. The flags are usually supposed to be client-visible — but no one audits what they're exposing.
Once you find one, the rest cascade. Here's what was also in the report:
| # | Severity | Class | Summary |
|---|---|---|---|
| 1 | HIGH | Info Disclosure | Feature flag disclosure (above) |
| 2 | LOW | Info Disclosure | Internal cohort identifiers leaked via subdomain JS |
| 3 | LOW | Info Disclosure | Server version exposed in HTTP headers |
| 4 | LOW | Info Disclosure | Build commit hashes exposed in static assets |
| 5 | LOW | Misconfiguration | Staging subdomain publicly accessible |
| 6 | LOW | Info Disclosure | Internal API endpoints discoverable via subdomain crawl |
| 7 | INFO | Info Disclosure | DNS zone walking possible (subdomain enumeration) |
| 8 | INFO | Info Disclosure | Email pattern verified via newsletter signup |
I bundled them all into a single report because Khan Academy's triage team is one of the best I've seen — they prefer the full picture over 8 separate tickets.
This isn't advanced work. It's all free, all scripted, and it runs in 20 minutes:
# Full chain (Kali Linux, all free)
subfinder -d target.com -silent -o subs.txt
cat subs.txt | httpx -status-code -title -tech-detect -silent -o live.txt
cat live.txt | nuclei -severity info,low,medium -silent
# Then: 30 minutes of reading the live responses
# Looking for:
# - Feature flag names (LD, Optimizely, Split.io, GrowthBook)
# - Build info (commit hashes, version strings)
# - Cohort identifiers (analytics cookies)
# - Staging environment hints (dev/staging/qa subdomains)If you're shipping an AI agent, three things to check today:
Here's the thing — this took 20 minutes of recon and 40 minutes of pattern recognition. I do it for a living.
If you want to know if your AI agent is leaking metadata the same way Khan Academy's was, I built a tool for it:
→ Try the free AI Prompt Tester → Take the AI Security Quiz
We'll do the same recon chain against your AI agent in real-time. If we find a HIGH-severity issue, you know you need a paid audit. If we don't, you get a 15-minute consult for free.
Schedule the call →