$17K Bounty — How a Simple Thank You Page Unlocked Critical PII via Recon & API Chaining
Not every high-value vulnerability starts with fuzzing or brute-force. Some begin with a cached page, an overlooked API, and a bit of curiosity.
In this write-up, I break down how a seemingly harmless thank-you page led me to a critical PII leak — and a five-figure bounty.
If your platform exposes post-registration data, this is your cautionary tale.
Vulnerability Overview
A public endpoint at:
https://targetsite.com/thanks?code=*
returned sensitive data post-registration — no login required. The exposed PII included:
- Full Name
- Email Address
- Date of Birth / Age
- Last 4 Digits of Credit Card
- Mobile Phone Number
This introduced significant risk of identity theft, phishing, and financial fraud.
Discovery Process
Step 1: Passive Recon
While I’m not a hardcore recon enthusiast — since I prefer a more manual, hands-on approach — I always start with a quick recon phase. This typically includes subdomain enumeration, WaybackURL analysis, and visual mapping with Aquatone before diving into active testing.
Using tools like waybackurls and gau, I identified old, cached URLs exposing registration codes for the site.
echo "targetsite.com" | waybackurls | grep 'code'
The registration tokens followed a hex-based format. Not trivially brute-forcible — but indexed pages already exposed working values.
However, passive recon alone wasn’t enough to qualify this as a critical issue. The challenge: how to get valid tokens without relying on old archives?
At this point, I had valid code values—but this alone wasn’t enough to mark the bug as critical.
Step 2: Getting Fresh Codes
I needed a way to obtain current, valid codes.
My attempts:
- Attempt 1: Brute-forcing token endings — no success.
- Attempt 2: Pattern detection using AI models (Claude, ChatGPT) — helpful, but no consistent pattern emerged.
- Attempt 3: Deep dive into the application.
At this point, I knew there was no “magic trick” coming — so I moved on to a deeper analysis of the application. While inspecting the JavaScript files, I discovered an unauthenticated endpoint that returned a registration code when queried with a numeric ID.
Although the endpoint itself looked simple, it would have been nearly impossible to understand its significance without the earlier discovery of the Wayback URLs that revealed how those codes were used. That connection was the key to turning this into a critical finding.
https://targetsite.com/api/invite/id/XXXXX
This public API returned:
{ "code": "ABC123456789" }These values could be used directly in the vulnerable endpoint to pull PII.
Step 3: Automation
I built a Python script to iterate over ID values, retrieve codes, and build working PII-leaking links. The result: thousands of exposed user records.
Impact
- Unauthenticated access to PII
- Data indexed by search engines and Wayback Machine
- Violates GDPR, CCPA, and PCI-DSS
This was a textbook case of:
- Insecure Direct Object References (IDOR)
- Poor caching policies
- Broken access control
Result
The vulnerability was recognized as critical and rewarded with a $15,000 bounty + $2,000 bonus.
Bug bounty isn’t just about payloads and scanners — it’s about thinking critically, analyzing every possible vector, and truly understanding how an application works.
In this case, the vulnerability was hiding in plain sight. It took passive recon, manual digging, and a bit of creative thinking to connect the dots. And yes — luck played a role, as it often does in bug hunting. But like most things, luck tends to show up more often when you invest the time.
Every overlooked endpoint, every old cached URL, and every small pattern in the code could be the start of a high-impact find.
So keep digging. The bugs are there.
Written by @g4mb4 — Top 5 HackerOne researcher in Argentina, founder of OliveX.