top of page

Exploiting PDF Generation -A Case Study in SSRF and JavaScript Injection

  • Writer: idan ba
    idan ba
  • 3 minutes ago
  • 4 min read

During a routine penetration test for one of our clients the application we were testing offered a familiar feature: the ability to generate PDF invoices that would later be sent to customers.


We quickly realized that some parts of the PDF’s content could be influenced by user input. Digging deeper, we examined the generated PDF files and discovered that the application was using SelectPdf, a popular .NET library.


Going over the documentation of SelectPDF, we've noticed the following statement

“Check the content of the web page being converted. Look for code (especially javascript) that might harm your system. Sanitizing user input can be difficult and attackers can sometimes find a way around the protection."

That fact immediately caught our attention. If the conversion process accepted JavaScript from untrusted sources, there could be a chance to sneak in something more dangerous.


Turning HTML into an Exploit


After some experimentation, we confirmed that we could inject JavaScript into the generated PDF. One of our test payloads looked like this:


The Payload that caused the SSRF generator to create an out-of-bounds HTTP request
The Payload that caused the SSRF generator to create an out-of-bounds HTTP request

When the backend processed this payload and rendered it into a PDF, something interesting happened - we were able to fetch and display the contents of the URL http://169.254.169.254/latest/meta-data/instance-id which proves that the system is vulnerable to SSRF!


The Generated PDF contained the results of the out-of-bound HTTP request (EC2 instance id)
The Generated PDF contained the results of the out-of-bound HTTP request (EC2 instance id)


What does this payload do?


The payload is a simple JavaScript snippet that issues an AJAX HTTP request from the server-side environment where the PDF is generated. Then the results will go in the title of the PDF.


The target, http://169.254.169.254/latest/meta-data/instance-id, is not just any address it’s the AWS EC2 instance metadata service, which sometimes exposes sensitive details about the cloud environment.


Accessing this endpoint revealed the unique ID of the cloud instance.

In short: this wasn’t just a script injection. It was a classic Server-Side Request Forgery (SSRF) via a PDF generator.


<script>
const xhr = new XMLHttpRequest();
xhr.open('GET', 'http://169.254.169.254/latest/meta-data/instance-id', true);
xhr.onreadystatechange = function () {
  if (xhr.readyState === 4 && xhr.status === 200) {
    document.write(xhr.responseText)

  }
};
xhr.send();
</script>


Insecure By Default


One of the more troubling aspects we discovered is the security design of SelectPdf itself. By default, the library allows JavaScript execution inside generated PDFs. This means that unless developers explicitly disable the feature, any injected script can run during PDF rendering opening the door for exploits like the one we demonstrated.


The documentation of SelectPDF on how to disable JavaScript and local file access.
The documentation of SelectPDF on how to disable JavaScript and local file access.


Why PDF Generation is Risky


PDF generation is extremely common in modern web applications: invoices, reports, tickets, contracts, and more are often built dynamically. To make this easier, developers rely on HTML-to-PDF libraries that allow them to style documents with familiar web technologies.


But here’s the problem - many of these libraries were never designed with strong security boundaries in mind. They parse HTML, CSS, JavaScript, and sometimes even SVG files all of which can carry risky payloads if not properly sanitized.


Over the years, multiple high- and critical-severity vulnerabilities have been discovered in popular PDF generator libraries. A few notable examples:


  • CVE-2023-23924 (Dompdf, PHP library) – Critical (CVSS 9.8–10) - Bypass in SVG parsing allows attackers to exploit URI validation weaknesses, that will lead to the very least to an arbitrary file deletion and even remote code execution, depending on classes that are available..


  • CVE-2019-15138 (html-pdf, Node.js) – High (CVSS ~7.5) - Arbitrary file read vulnerability, where crafted HTML could cause the converter to embed sensitive files (like /etc/passwd) directly into PDFs.


  • CVE-2024-9935 - High (CVSS 7.5) - A PDF Generator Addon for Elementor Page Builder plugin for WordPress is vulnerable to Path Traversal.



Quick Note - The vulnerability that we've found is not a CVE in SelectPDF but rather a misconfiguration (Since its was configured to allow JavaScript execution)



Not Just PDFs, Image Generators Too


PDF generators aren’t the only culprits. Image processing libraries are another notorious weak spot, heavily targeted by attackers for similar reasons. They handle complex, often user-supplied input, and a small parsing bug can lead to catastrophic results.


One of the most famous examples is the ImageTragick vulnerability (CVE-2016-3714) in ImageMagick, which allowed attackers to execute arbitrary code simply by uploading a crafted image.


More recently, CVE-2023-43115 affected the libvips image processing library, exposing applications to out-of-bounds reads and potential code execution.


These cases show that any server-side content generator whether it’s PDFs or images can become a serious attack surface.



Conclusion


PDF generation seems like a harmless utility feature, but as our pentest showed, it can become a powerful attack vector if not handled securely. Libraries that transform HTML into PDFs often carry the same risks as rendering untrusted web pages in a browser XSS, SSRF, RCE, and sensitive data exposure.



For developers and security teams, this means treating PDF and image generation with the same caution as any other untrusted input processing: sandbox execution, sanitize inputs, and keep libraries up to date and configuring their security settings properly.



 
 
bottom of page