Hackers Abuse Pandoc SSRF (CVE-2025-51591) to Target AWS IMDS — How It Works and How to Protect Your Cloud

TL;DR

Attackers have been observed exploiting a Server-Side Request Forgery (SSRF) bug in Pandoc (CVE-2025-51591) to try to access the AWS Instance Metadata Service (IMDS) and steal temporary EC2 IAM credentials. The attempts were largely blocked where IMDSv2 was enforced. If you process untrusted HTML with Pandoc, treat inputs as hostile: sanitize, or render with -f html+raw_html / --sandbox, and enforce IMDSv2 + least-privilege IAM roles across EC2.

What Happened (Short Version)

Security researchers at Wiz found real-world attempts to exploit a Pandoc vulnerability (CVE-2025-51591) that renders <iframe> tags in HTML. Attackers crafted HTML documents whose iframe src pointed at the AWS Instance Metadata Service (169.254.169.254) to try to read instance metadata paths such as /latest/meta-data/iam and /latest/meta-data/iam/info. Those metadata paths can return temporary IAM credentials for EC2 instances — and if stolen, those credentials let attackers call AWS APIs (S3, RDS, DynamoDB, etc.) without needing long-lived keys.

Why This Matters

IMDS exists to let software running on EC2 obtain identity and configuration information without storing secrets on disk. But IMDS is reachable from the instance itself (link-local address). When a web application or utility running on an instance is vulnerable to SSRF, an attacker can make that app request metadata on their behalf — effectively turning the app into a proxy to internal services. That’s a common and high-impact cloud attack path because it can bypass perimeter defenses and IP whitelists.

The Technical Root Cause

• Vulnerability type: SSRF (Server-Side Request Forgery)
• Where: Pandoc’s HTML rendering — Pandoc renders <iframe> elements by default
• Exploit vector: Attackers submit or trick an application into processing crafted HTML with <iframe src="http://169.254.169.254/...>. Rendering could expose metadata.
• Why IMDSv2 helps: IMDSv2 requires a session token (via PUT + header X-aws-ec2-metadata-token), blocking simple SSRF grabs.

What Wiz Observed

Wiz reported in-the-wild exploitation attempts beginning in August and continuing for several weeks. In observed cases, the attacks were unsuccessful when targets enforced IMDSv2. The researchers also saw parallel attempts targeting other SSRF flaws (for example, in ClickHouse) against other cloud providers.

Recommended Mitigations — Short Checklist

• Enforce IMDSv2 on all EC2 instances.
• Disable IMDSv1 where possible; require token flow.
• Apply Pandoc mitigations when processing untrusted HTML:
  • Use -f html+raw_html or --sandbox to prevent iframe inclusions.
  • Sanitize inputs server-side: strip or validate dangerous tags.
• Follow the principle of least privilege (PoLP): give roles only needed permissions.
• Harden web apps against SSRF: validate URLs, block 169.254.0.0/16, use allowlists.
• Monitor for unusual metadata access; enable GuardDuty or IDS alerts.
• Keep Pandoc updated and follow security advisories.

Recommended Developer / Server Configuration for Pandoc

If you must render external or user-submitted HTML with Pandoc, choose one of these safer modes:

• pandoc -f html+raw_html ... — disables automatic inclusion of external content via iframe src.
• pandoc --sandbox ... — runs Pandoc in a restricted mode that prevents unsafe operations.
• Additionally, sanitize HTML server-side (for example, remove <iframe> tags entirely) before handing content to Pandoc.

Real Examples and Historical Context

SSRF against cloud metadata is a well-known and practical technique — Mandiant and others have documented attackers abusing IMDS via SSRF (for example CVE-2021-21311 used against Adminer). The Pandoc exploitation attempts illustrate that even less prominent tools can become vectors when they process untrusted input and render external references.