CVE-2025-51591 Overview
CVE-2025-51591 is a Server-Side Request Forgery (SSRF) vulnerability in JGM Pandoc v3.6.4, the widely used universal document converter. Attackers can inject a crafted <iframe> element into untrusted HTML content processed by Pandoc, causing the converter to issue server-side HTTP requests to attacker-chosen destinations. When Pandoc runs inside cloud workloads, this behavior can be abused to reach internal services such as cloud metadata endpoints (for example, the AWS Instance Metadata Service), potentially exposing credentials and other infrastructure data. The vulnerability is tracked as CWE-918: Server-Side Request Forgery.
Critical Impact
An attacker who controls input passed to Pandoc can coerce the host to fetch attacker-specified URLs, enabling reconnaissance and theft of internal data such as cloud instance metadata.
Affected Products
- JGM Pandoc v3.6.4
- Pandoc deployments that process untrusted HTML without the --sandbox flag
- Pandoc invocations using an external --pdf-engine such as wkhtmltopdf
Discovery Timeline
- 2025-07-11 - CVE-2025-51591 published to the National Vulnerability Database
- 2026-04-15 - Last updated in the NVD database
Technical Details for CVE-2025-51591
Vulnerability Analysis
Pandoc converts between many document formats and, by default, can retrieve and parse remote resources referenced inside HTML input. When an attacker supplies HTML containing a crafted <iframe> whose src attribute points to an internal address, Pandoc resolves and fetches that resource during conversion. The contents returned by that fetch may then be embedded into the rendered output document, leaking internal data back to the attacker. Public proof-of-concept code demonstrates the issue against the AWS metadata endpoint at http://169.254.169.254/, which exposes IAM credentials when reachable. A working PoC is published at Malayke/CVE-2025-51591-Pandoc-SSRF-POC, and the Wiz Research team documented related Instance Metadata Service (IMDS) abuse patterns in their IMDS anomaly hunting writeup.
Root Cause
The root cause is Pandoc's default willingness to dereference external resources embedded in untrusted HTML during conversion. The renderer treats <iframe> and similar fetching primitives as legitimate document content and resolves them without restricting the destination to safe networks. Without an allowlist or sandbox, requests targeting link-local, loopback, or RFC1918 ranges are issued from the host running Pandoc. Maintainer discussion of the behavior and proposed hardening is tracked in Pandoc issue #11261 and pull request #11262.
Attack Vector
The attack vector is network-based and requires no authentication or user interaction, but successful exploitation depends on the attacker being able to submit HTML to a Pandoc-driven pipeline. Common targets include document conversion services, report generators, and PDF rendering backends that accept user-supplied Markdown or HTML. The attacker embeds an iframe or similar fetching element pointing at an internal URL, then reads the response from the converted output. When Pandoc is paired with an external PDF engine such as wkhtmltopdf, the engine itself may introduce additional SSRF surface, as seen previously in CVE-2022-35583.
No verified exploit code is reproduced here. See the public proof-of-concept linked above for technical details.
Detection Methods for CVE-2025-51591
Indicators of Compromise
- Outbound HTTP requests from a Pandoc host to link-local addresses such as 169.254.169.254, fd00:ec2::254, or other metadata service endpoints.
- Pandoc process activity correlated with network connections to internal RFC1918 ranges that the conversion workload does not normally contact.
- Rendered output documents containing fragments of internal service responses, IAM credential structures, or cloud metadata JSON.
Detection Strategies
- Inspect HTML and Markdown submitted to conversion pipelines for <iframe>, <embed>, <object>, and <img> tags whose src attributes resolve to internal or link-local addresses.
- Alert on pandoc or wkhtmltopdf processes initiating outbound connections to addresses outside an explicit allowlist of expected hosts.
- Correlate document-conversion job identifiers with egress network logs to identify jobs that produced anomalous fetches.
Monitoring Recommendations
- Forward process, network, and command-line telemetry from systems running Pandoc to a centralized analytics platform for correlation.
- Monitor IMDS access patterns and enforce IMDSv2 with hop-limit restrictions on cloud instances that run Pandoc workloads.
- Track Pandoc version inventory across build servers, CI runners, and document services to identify hosts still running v3.6.4 or earlier.
How to Mitigate CVE-2025-51591
Immediate Actions Required
- Run Pandoc with the --sandbox option whenever it processes untrusted input, which restricts file and network access during conversion.
- Move document conversion to pandoc-server, which enforces sandboxing by default for hosted workloads.
- Enforce IMDSv2 with a low hop limit on cloud instances so that SSRF against 169.254.169.254 cannot retrieve credentials without a session token.
- Restrict egress from Pandoc hosts so they cannot reach metadata services, loopback, or internal management ranges.
Patch Information
Upgrade to a Pandoc release that incorporates the upstream hardening discussed in pull request #11262 and the related commit 67edf7c. Review the maintainer guidance in Pandoc discussion #11200 and issue #10682 for the recommended configuration when handling untrusted HTML.
Workarounds
- Pre-process incoming HTML to strip or rewrite tags that trigger remote fetches, including <iframe>, <embed>, <object>, <link>, and remote <img> sources.
- Run Pandoc inside a network namespace or container with no route to internal services or metadata endpoints.
- Avoid pairing Pandoc with external PDF engines such as wkhtmltopdf unless those engines are also patched and sandboxed.
# Configuration example: invoke Pandoc safely on untrusted input
pandoc --sandbox \
--from=html \
--to=pdf \
--output=/tmp/out.pdf \
/tmp/untrusted-input.html
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


