How do a quiet open‑source tool and a cloud provider’s metadata service combine to make keys disappear? The troubling answer lies in a newly observed attack chain: adversaries exploiting a Server‑Side Request Forgery (SSRF) in Pandoc to coax Amazon EC2 instances into handing over AWS credentials from the Instance Metadata Service. The vulnerability, tracked as Pandoc CVE-2025-51591, has been seen in the wild and highlights how routine developer utilities can become the pivot for cloud compromise.
Pandoc CVE-2025-51591: how the exploit works
Pandoc is a ubiquitous document converter used to transform files between Markdown, HTML, LaTeX, Word and other formats. Because it’s often embedded in CI/CD pipelines, content services, and developer tooling, it frequently runs on servers that have network access to internal cloud endpoints. An SSRF in such a context allows an attacker to trick Pandoc into making HTTP requests to arbitrary addresses — including AWS’s Instance Metadata Service at 169.254.169.254.
When a vulnerable Pandoc process issues requests to IMDS, it can fetch temporary IAM credentials and session tokens associated with the instance role. Those credentials are powerful: they can read S3 buckets, access databases, start or stop instances, and assume other roles. The practical result of Pandoc CVE-2025-51591 exploitation is rapid credential theft and the potential for lateral movement and data exfiltration across an AWS account.
Why this matters for cloud defenders
Traditional network assumptions — that processes on an instance won’t leak internal metadata to untrusted parties — break down in SSRF scenarios. The consequences are concrete:
– Loss of temporary AWS credentials retrieved from IMDS, enabling unauthorized access and lateral movement.
– Compromise of resources tied to those credentials, from sensitive S3 objects to management interfaces.
– Persistence and privilege escalation if attackers obtain role‑assumption or long‑lived credentials downstream.
Wiz’s telemetry shows active exploitation beyond proofs‑of‑concept, underlining that supply‑chain issues and innocuous utilities can be weaponized into cloud‑native attacks. The incident is a reminder that even small, well‑maintained open‑source projects can become crucial nodes in an attacker’s chain when deployed inside cloud environments.
Immediate mitigation and hardening steps
Defenders can take several practical, high‑impact actions now:
– Inventory deployments: identify where Pandoc and similar server‑side document tooling run across build systems, CI pipelines, web services, and containers.
– Patch or disable: apply vendor patches promptly. If a patch isn’t available, disable risky conversion features or restrict document handling in untrusted contexts.
– Enforce IMDSv2: require session tokens for metadata access. IMDSv2 substantially reduces the risk of credential leakage from SSRF, but many workloads still allow IMDSv1.
– Restrict egress: implement network egress controls to block access to metadata endpoints (169.254.169.254) from services that don’t require it.
– Apply least privilege: tighten IAM role assignments so temporary credentials expose only the minimum permissions necessary.
– Monitor and hunt: use security vendor signatures, host telemetry and cloud logs to search for anomalous requests to internal endpoints or unexpected token usage.
Policy and supply‑chain implications
This incident also has broader implications for procurement, policy and open‑source stewardship. A flaw in a benign utility can escalate quickly when it executes in an internet‑connected or cloud‑connected environment. Organizations should consider:
– Requiring secure defaults for software deployed in cloud environments.
– Clarifying responsibilities for timely patching across vendors, cloud operators and system owners.
– Incorporating supply‑chain risk assessments into procurement and deployment decisions.
– Funding maintainers or contributing fixes to critical open‑source projects used in production clouds.
The role of the ecosystem
Maintainers of Pandoc and similar projects face a difficult balance: release rapid fixes and clear advisories while accounting for a wide range of deployment scenarios. Cloud providers can help by making safe defaults more visible and by offering tooling to detect anomalous internal requests. Security vendors and enterprises should share telemetry and indicators of compromise to accelerate detection and containment.
Conclusion: treat Pandoc CVE-2025-51591 as a cloud warning shot
Pandoc CVE-2025-51591 is a practical warning that the boundary between local software vulnerabilities and cloud credential compromise is thinner than many organizations assume. As cloud use grows, the incentives for attackers to chain small bugs into large breaches will only increase. Inventory, patching, network controls, IMDSv2 adoption and least‑privilege IAM are achievable defenses that materially reduce risk. Organizations that move quickly on these measures will be better positioned to prevent the next utility from becoming an exploit chain that steals EC2 keys.
