Stirling-PDF: AI create-pdf-from-html-agent skips HTML sanitization enabling WeasyPrint SSRF and local file read
Stirling-PDF versions before 3.0.0 are affected, and the endpoint is reachable without credentials when security.enableLogin is false. Fixed in 3.0.0.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- Fix
- Fixed in 3.0.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Stirling-PDF, a locally hosted web application for PDF operations, is affected through its AI create-PDF-from-HTML endpoint, which skips HTML sanitization before passing content to WeasyPrint. An attacker can use this to make the server send requests to internal or cloud-metadata addresses and to embed local files readable by the Stirling-PDF process into generated PDFs.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
Stirling-PDF is a locally hosted web application that facilitates various operations on PDF files. Prior to 3.0.0, POST /api/v1/ai/tools/create-pdf-from-html-agent accepts attacker-controlled htmlContent and passes it to WeasyPrint without CustomHtmlSanitizer, unlike the sanitized /api/v1/convert/html/pdf control path. HTTP and HTTPS resource references can make server-side requests to internal or cloud-metadata destinations, while file references can embed local content readable by the Stirling-PDF process into the generated PDF. The endpoint is reachable without credentials when security.enableLogin is false, and the flaw is distinct from earlier Stirling-PDF WeasyPrint vulnerabilities in older conversion paths. This issue is fixed in version 3.0.0.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Stirling-Tools Stirling-PDF
fixed in 3.0.0
References 4
GitHub · Stirling-Tools/Stirling-PDF
Questions about CVE-2026-119343
What does this mean?
The AI create-pdf-from-html agent skips HTML sanitization, so crafted HTML can make the server send requests to internal or cloud-metadata hosts and read local files that the Stirling-PDF process can read.Source: github.com
Am I affected, and how do I check?
Stirling-PDF versions before 3.0.0 are listed as affected. The endpoint is unauthenticated when security.enableLogin is false, so check the installed version and that setting in the configuration.Source: github.com
What should I do about it?
Upgrade Stirling-PDF to 3.0.0 or later, which is the listed fixed version.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data