SSRF When Generating PDFs from User-Controlled HTML

[RealestName]

Hello,

During a recent engagement, I came across an "Export to PDF" function which takes user controlled HTML and passes it to the pandoc PDF generator. While testing, I discovered that the PDF generation library is vulnerable to Server-Side Request Forgery (SSRF) when rendering PDFs from HTML containing <iframe> elements. An attacker can exploit this by embedding an iframe with a URL pointing to internal resources, potentially exposing sensitive data or interacting with internal services.

[tarleb]

I don't see that as a security issue with pandoc, but we could consider adding an item for that to the "Security" section in the manual. Would you want to submit a PR?

[tarleb]

Also note that you can prevent pandoc from resolving iframe elements by enabling the raw_html option.

[RealestName]

While testing, I noticed that JavaScript execution was blocked, meaning some security measures were implemented. This scenario is similar to CVE-2022-35583 (Which is set to a 9.8 in severity, and even the POC uses the same payload). I believe that the best security solution would be to set the raw_html option as enabled by default and make it the user's responsibility.

[RealestName]

I don't see that as a security issue with pandoc, but we could consider adding an item for that to the "Security" section in the manual. Would you want to submit a PR?

I think it would be best to add an item to the security section, if possible.

[jgm]

Could you describe the problem in more detail? You have an HTML file, with an iframe whose src attribute points to something internal. If you view this in a browser, the internal thing will show up in the iframe, now? And so if you ask pandoc to produce a PDF, the PDF will also include the internal thing?

So, what is the risk you envision? If you use pandoc to convert an HTML file containing private information, the private information will end up in the resulting file. But that is true whether or not the information is included via an iframe.

[tarleb]

I think the issue opens up when offering HTML-to-PDF-conversions as a service: A server in an internal company network might leak information that's only available from within the network.

[RealestName]

Could you describe the problem in more detail? You have an HTML file, with an iframe whose src attribute points to something internal. If you view this in a browser, the internal thing will show up in the iframe, now? And so if you ask pandoc to produce a PDF, the PDF will also include the internal thing?

So, what is the risk you envision? If you use pandoc to convert an HTML file containing private information, the private information will end up in the resulting file. But that is true whether or not the information is included via an iframe.

The key risk is that an attacker can exploit this behavior to force the server to make requests to internal resources, this is known as Server-Side Request Forgery (SSRF).

Let's consider the following attack scenario:

Suppose an attacker submits or uploads an HTML file with an <iframe> like this:

<iframe src="http://localhost/admin" />

When the server processes this HTML to generate a PDF, the server itself will attempt to fetch the content at http://localhost/admin (or any internal endpoint).

Impact:

This request could reach internal services that are not intended to be publicly accessible.
The attacker may gain access to sensitive data, internal admin panels, cloud metadata endpoints, or other restricted resources.
Even if the content isn’t directly rendered in the PDF, timing-based attacks, error messages, or other indirect data leakage vectors could still reveal information.

Why This Is Dangerous:

Unlike a browser where same-origin policies apply, pandoc runs on the server without restriction, making this a powerful SSRF vector. The risk is not just leaking private information in an iframe, it's the ability of an attacker to trigger unintended requests to internal services.

[jgm]

As noted in the Security section, our recommendation is to use --sandox when running on a server, or even better to use pandoc-server. Both will block this kind of operation.

Note that item 2 of security already mentions this threat for HTML.

[jgm]

OK, I see that the threat is somewhat different from normal include files, because it could be an HTTP request. Perhaps splitting item 2 into two parts, one for standard include and one for HTML iframe, would make sense.

[jgm]

Let me know if anything in my commit should be changed.