This wasn't a sophisticated cyberattack. It was an escalation — a chain of small, overlooked issues in web security. It started with text formatting and ended with cloud security keys.

Here's how I found this vulnerability chaining in action and why features like PDF generators need more scrutiny.

The Innocent Beginning: A Certificate Feature

While testing a learning platform, a $5 course offered a certificate. A simple PDF generator lets you enter your name, title, and a quote.

The request looked harmless:

{
  "name": "Your Name",
  "title": "Your Title",
  "quote": "Your Motivational Quote"
}

But the title field had no input sanitization. When it <i>Your Title</i> was tested, the PDF showed italicized text.

This was HTML injection. Not flashy, but a solid first step in any exploit chain.

More Than Text

If basic HTML was rendered, what else could the PDF rendering engine process? The goal was to see if it would fetch external resources.

A test payload was sent:

"title": "<iframe src='http://my-server.com/probe'></iframe>"

Moments later, an HTTP hit was received from the target's server IP.

The simple HTML injection was now a confirmed Server-Side Request Forgery (SSRF). The backend PDF rendering service was fetching remote content.

Reaching AWS Metadata

An SSRF is powerful if it can reach internal systems. A common test in cloud security is the AWS metadata endpoint.

A new payload was crafted:

"title": "<iframe src='http://169.254.169.254/latest/meta-data/'></iframe>"

The generated PDF listed metadata paths. The server was on AWS. Further probing accessed the IAM role security credentials endpoint, and the PDF output contained:

{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "..."
}

Temporary AWS credentials were exposed via the PDF button. This is the core of vulnerability chaining: HTML → SSRF → AWS metadata leak.

How This Vulnerability Chaining Works

This works because modern PDF rendering often uses headless browsers (like Puppeteer or wkhtmltopdf) that fetch all page assets — images, CSS, and iframes.

The system wasn't printing text; it was rendering a mini-webpage. My input became part of that page, forcing the server to make requests on my behalf.

As one developer put it:

"A PDF generator is often a headless browser in disguise. What you give it, it will render."

Key Takeaways for Security Research

This bug bounty finding highlights critical lessons:

• Test All Output Formats: An input might be safe in HTML but dangerous in PDFs, reports, or emails.
• Assume Chaining: A low-severity bug (HTML injection) can be the first link in a critical chain. Always ask, "What feature processes this data next?"
• Defensive Design for Developers: Sanitize inputs for all downstream uses, not just the immediate webpage. Treat data passed to PDF generators with the same caution as data going into your database.

The Real Win: The issue was disclosed, the credentials were rotated, and the vendor addressed the flaw. The true reward in security research is making systems safer, not just the bounty.

TL;DR: A basic HTML injection in a PDF certificate generator was chained into an SSRF, leading to AWS credential exposure. It shows why web security requires thinking about how data flows through every part of an application.

Want to dive deeper into ethical security research? Follow for more write-ups, and always remember to test responsibly and disclose ethically.