CVE-2025-51591: Pandoc, SSRF, and AWS Metadata Credential Theft

Executive Summary

CVE-2025-51591 is an instructive example of why cloud-context vulnerabilities must be analyzed as end-to-end attack paths rather than isolated application bugs. The issue centered on an SSRF-class behavior in Pandoc's document processing pipeline, where untrusted input content could cause the server-side renderer to issue HTTP requests to attacker-specified destinations. In a cloud environment—particularly on AWS EC2—that behavior becomes dangerous at speed if the workload's networking context allows it to reach the instance metadata service.

Once that path exists, the description “document conversion bug” is no longer adequate. The accurate framing is “application-layer SSRF combined with cloud identity exposure”—a combination that can escalate from a package-level finding to environment-wide credential access in a single exploit chain.

Why Document Conversion Workflows Carry More Risk Than They Appear To

Tools such as Pandoc occupy a deceptively trusted position in many engineering and content pipelines. Their stated function—converting between document formats such as Markdown, HTML, LaTeX, and PDF—sounds purely utilitarian. But the execution model behind that utility is complex. During rendering, these converters routinely resolve external references, fetch embedded resources, process include directives, and handle remote content as first-class inputs.

When that outbound fetch behavior is not explicitly constrained at the application or network layer, the attacker can redirect the converter's trust in external content into an internal request engine—one that operates with the full network privileges of the server process.

The SSRF-to-IMDS Exploitation Chain

In AWS, the instance metadata service is accessible at the link-local address 169.254.169.254 and is reachable only from within the instance itself. This address-based access control is precisely what makes SSRF so operationally dangerous in cloud environments: the attacker has no direct path to the metadata service from the internet, but the vulnerable application running on the instance does.

A malicious document can embed a crafted reference—formatted as an image source, an include directive, or any other fetchable object—that points to the metadata endpoint. When the converter resolves that reference during document generation, the server issues the HTTP request against the metadata service on the attacker's behalf.

The resulting exploit chain is clean and repeatable:

attacker submits specially crafted document content for conversion.

the renderer resolves the embedded external reference during document generation.

the server-side process fetches the AWS instance metadata endpoint internally.

the metadata response—including IAM credential material—is reflected back through the output, embedded in logs, or otherwise exfiltrated to the attacker.

This is textbook SSRF logic. What elevates it from an interesting application bug to an operationally severe cloud incident is the IAM credential material that sits at the other end of the metadata path.

Why Temporary IAM Credentials Are Not a Meaningful Safeguard

When the attacker reaches the IAM credentials endpoint on the EC2 instance metadata service, the response includes temporary access material: an AccessKeyId, a SecretAccessKey, and a session token. These credentials are time-bounded by the instance's role refresh cycle, but brevity does not equal harmlessness.

If the instance role is over-privileged—as is disturbingly common in production cloud environments—even short-lived credentials can provide read access to S3 buckets, secrets in AWS Secrets Manager or Parameter Store, database connection strings, internal service endpoints, SQS queues, and cloud management APIs. The time window is often sufficient for data exfiltration, pivot actions, or persistence establishment before the credentials expire.

In cloud incident investigations, the blast radius is determined almost entirely by the IAM role attached to the workload, not by the SSRF mechanism itself.

How IAM Role Design Determines Actual Impact

The same underlying vulnerability produces dramatically different operational impact depending on the IAM role attached to the affected EC2 instance. A least-privilege role with tightly scoped permissions may limit abuse to a narrow set of services. An over-privileged role—one that accumulated permissions organically over time, or was granted broad access “for convenience”—can transform the identical vulnerability into environment-wide data access and lateral movement capability.

This is the essential insight that separates cloud vulnerability analysis from traditional on-premises assessment. The risk does not live solely in the application code. It lives at the intersection of the code path, the metadata access boundary, and the IAM permission model. All three must be evaluated together to understand actual exposure.

Defensive Mitigations

A comprehensive defensive response addresses the problem at multiple layers:

enforce IMDSv2 (token-based) access on all EC2 instances to eliminate trivial SSRF-to-metadata exploitation; IMDSv1 is significantly more exploitable under SSRF conditions.

apply the principle of least privilege to all instance IAM roles, eliminating permissions that are not required by the specific workload.

constrain outbound fetch behavior in document conversion services at both the application configuration level and through network egress controls.

treat document processing services as trust-boundary components, not background utilities, and apply appropriate network segmentation.

log and alert on unexpected outbound connections from conversion workloads.

CVSS Vector and Affected Versions

CVE-2025-51591 carries a CVSS 3.1 score of 8.8 (High):

~~~

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N

~~~

The Changed scope (S:C) reflects that exploitation reaches beyond the vulnerable Pandoc process — the AWS IAM credential access affects the broader cloud environment, not just the local application.

| Component | Affected Versions | Remediation |

|---|---|---|

| Pandoc | Versions allowing unrestricted external URL fetch during render | Upgrade + configure --sandbox or network egress restrictions |

| AWS EC2 (IMDSv1) | Any instance with IMDSv1 enabled | Enable IMDSv2 (aws ec2 modify-instance-metadata-options --http-tokens required) |

| AWS IAM Roles | Any over-privileged instance role | Apply least-privilege; scope permissions to specific resources and actions |

Detection Signals

~~~yaml

title: Detect SSRF Attempt Against AWS IMDS via Document Converter (CVE-2025-51591)

status: experimental

description: Detects HTTP requests to AWS metadata IP from document processing service

detection:

condition: selection

selection:

dst_ip: '169.254.169.254'

process_name|contains:

'pandoc'.

'wkhtmltopdf'.

'headless'.

logsource:

category: network_connection

product: linux

~~~

Also monitor AWS CloudTrail for GetSecretValue, ListBuckets, or AssumeRole calls from EC2 instance roles associated with document conversion workloads — these may indicate IAM credential abuse after successful SSRF.

MyVuln Perspective

MyVuln should present CVE-2025-51591 as a contextual cloud risk requiring multi-dimensional analysis, not merely as an SSRF finding against a document conversion utility. MyVuln'ün Cloud Risk Correlation modülü bağımlılık zekasını, instance metadata maruziyetini ve bağlı IAM ayrıcalığını tek tutarlı bir risk değerlendirmesinde ilişkilendirir — enabling security teams to move from a “Pandoc package alert” to a prioritized cloud identity compromise path with actionable remediation. The synthesis is what converts a package-level finding into a visible, prioritized cloud identity compromise path with actionable remediation guidance.