How a $5,000 “Low Severity” Bug Turned Into the Ultimate Admin Trap

Three weeks ago, I was looking at a high-profile healthcare platform on HackerOne. Thousands of hackers had poked at it over the last three years. The main application was a fortress — sanitized inputs, strict Content Security Policy (CSP), robust OAuth flow, and heavily rate-limited API endpoints.

I almost closed the tab. But then I decided to check their secondary feature: the "Export My Medical History" feature.

What started as a trivial, $200-worth formatting glitch ended up triggering a full-scale emergency response and a $5,000 bounty payout.

Here's how it happened — and the unexpected twist that made the security team double my reward.

Phase 1: Finding the "Boring" Flaw

When you request a PDF export of your account history, the server spins up a headless Chrome browser in the background, renders your personal details into an HTML template, and converts it into a downloadable PDF.

I noticed that if I updated my profile name to include simple HTML tags like <h1>Test</h1>, the generated PDF actually rendered my name in big, bold text.

Result? HTML Injection.

Normally, HTML Injection in a PDF generator gets you a small payout (maybe $200 to $500) because the impact is low. It only affects the user looking at their own downloaded PDF. You can't hack anyone else with it.

I was about to submit the report as a low-severity finding just to cover my coffee expenses for the week. But a voice in my head said: Push it a little further.

Phase 2: Upgrading to Server-Side Request Forgery (SSRF)

Instead of basic text, I tried injecting an <iframe> tag into my profile name to see if the internal PDF generator would try to render external content:

<iframe src="[http://my-interceptor-server.com](http://my-interceptor-server.com)"></iframe>

I updated my name, clicked "Export PDF," and waited.

Five seconds later, my interceptor server logged an incoming HTTP request. The headless browser rendering the PDF was actively visiting external websites.

I immediately escalated the payload to target internal resources:

<iframe src="[http://169.254.169.254/latest/meta-data/](http://169.254.169.254/latest/meta-data/)"></iframe>

When the PDF finished downloading, I opened it. Printed right on page two of my "Medical History" was the internal AWS metadata of the cloud server hosting the PDF service, including temporary IAM role tokens.

I had successfully turned a boring HTML injection into a critical Server-Side Request Forgery (SSRF).

The Plot Twist: The Auto-Triage Trap

At this point, I had a solid P1 (Critical) report. I wrote up a detailed Proof of Concept (PoC), attached the generated PDF, and hit submit.

Then came the twist.

About twenty minutes after I submitted the report, I noticed something strange in my server logs. My interceptor server was getting hit again by the same internal AWS IP address from the company's infrastructure.

I checked my HackerOne dashboard. The report hadn't been touched by a human analyst yet.

Why was their server still rendering my payload?

Then it clicked: Their internal security triage team had automated their ticket processing.

When a hacker submitted a report containing a PDF attachment, an automated backend script in their internal security dashboard opened the PDF, parsed the text, and rendered the contents for the security team to review.

Because my original payload was still embedded inside the PDF file I submitted, their internal administrative portal executed the malicious code automatically when their system processed my report.

My payload didn't just hit the isolated PDF generator — it executed inside their corporate internal network, triggering an SSRF that pulled the credentials of the internal security engine itself.

I didn't just find a bug in the app; my report unintentionally hacked the very tool they were using to triage my report.

The Payday and Triage

I immediately updated the ticket with a urgent warning:

"IMPORTANT: Do not open or process the attached PDF in your internal dashboard. The payload is active and will execute against your internal triage network."

The response was instantaneous. A lead security engineer stepped in, manually quarantined the ticket, and patched both vulnerabilities within hours.

StepImpact LevelInitial DiscoveryLow (HTML Injection in PDF)First EscalationHigh (SSRF via Headless Chrome)The TwistCritical (Internal Admin Automation Hijack)Final Bounty$5,000

Key Lessons for Bug Hunters

1. Never settle for Low-Severity: An HTML injection isn't the end of the road; it's an invitation to test for SSRF, Local File Inclusion (LFI), or XSS.
2. Understand the Pipeline: Always ask yourself: Where does my input go after I hit submit? Who (or what) processes it next?
3. Report Ethically: The moment you realize a vulnerability touches live internal systems or staff infrastructure, stop testing, document what happened, and inform the team immediately. Clear communication is what turns a good find into a massive bounty.