Hackers Exploit Pandoc CVE-2025-51591 to Target AWS IMDS and Steal EC2 IAM Credentials

Cloud security company Wiz has uncovered active exploitation attempts of a newly disclosed vulnerability in the Linux utility Pandoc, tracked as CVE-2025-51591 (CVSS score: 6.5). The flaw is a Server-Side Request Forgery (SSRF) issue, which allows attackers to exploit Pandoc’s handling of HTML documents containing <iframe> tags. Specifically, a crafted iframe can trick Pandoc into making unauthorized requests to sensitive internal resources such as the Amazon Web Services (AWS) Instance Metadata Service (IMDS).

The AWS IMDS is a key feature that provides runtime information about EC2 instances. When an IAM role is attached to an instance, the IMDS issues temporary credentials, enabling secure interactions with AWS services like S3, RDS, or DynamoDB—without storing long-term secrets on the machine. However, this convenience has also made IMDS a prime target for adversaries: if they can exploit an SSRF flaw, they can force an application to fetch IAM credentials from IMDS on their behalf, which can then be misused for data theft, persistence, or lateral movement.

This type of abuse has been observed before. For example, Mandiant reported in 2022 that a group tracked as UNC2903 had exploited SSRF flaws in Adminer (CVE-2021-21311) to steal AWS credentials and exfiltrate sensitive data. Researchers and security firms including Resecurity have warned that SSRF against IMDS can be high-impact, enabling attackers to bypass firewalls, perform reconnaissance, and access otherwise restricted internal assets.

The newly reported CVE-2025-51591 vulnerability in Pandoc arises from its default behavior of rendering iframe elements. Wiz observed attackers submitting HTML documents with iframes pointing at IMDS endpoints (169.254.169[.]254), targeting sensitive paths such as /latest/meta-data/iam/info and /latest/meta-data/iam/. Fortunately, the attacks were unsuccessful in AWS environments using IMDSv2, which requires session-oriented tokens to access metadata, preventing blind credential harvesting.

Wiz noted exploitation attempts dating back to August 2025, with attackers also probing other cloud environments, including Google Cloud Platform, by abusing unrelated SSRF vulnerabilities (e.g., in ClickHouse). This highlights that attackers are actively searching for exploitable SSRF entry points in lesser-known tools like Pandoc, not just high-profile web applications.

The Pandoc maintainers have stated that rendering iframes is intentional behavior. It is the responsibility of users to sanitize inputs or enable specific safety features (e.g., --sandbox or -f html+raw_html) when handling untrusted HTML.

Meanwhile, AWS security guidance continues to stress the importance of enforcing IMDSv2, which requires signed token-based access and prevents simple SSRF-based credential theft. Security experts also warn that AWS environments relying on IMDSv1 remain exposed if combined with vulnerable third-party applications.

What you should do

For Pandoc Users

• Avoid unsafe defaults: When processing HTML input, use either:
  • -f html+raw_html (to limit raw HTML processing), or
  • --sandbox (to prevent iframe content fetching).
• Sanitize untrusted input before feeding it into Pandoc. Treat uploaded or user-supplied documents as potentially malicious.
• Update Pandoc regularly to benefit from security-related fixes and clarifications.

For AWS EC2 Users

• Enforce IMDSv2 across all instances:
  • IMDSv2 requires session tokens, making it resilient against blind SSRF attacks.
  • Update your EC2 launch configurations and templates to default to IMDSv2.
• Disable IMDSv1 wherever possible, as it remains a common attack vector.
• Apply the Principle of Least Privilege (PoLP) to IAM roles:
  • Ensure that each EC2 instance has only the minimal IAM permissions necessary.
  • Limit the blast radius if credentials are compromised.
• Use GuardDuty or equivalent monitoring tools to detect suspicious IMDS access attempts.

If you are worried about any of the threats outlined in this bulletin or need help in determining what steps you should take to protect yourself from the most material threats facing your organisation, please contact your account manager, or alternatively Get in touch to find out how you can protect your organisation.