Stirling-PDF: SVG→PDF local file read (LFI) via SVG-sanitizer and Batik same-origin bypass
Affects Stirling-PDF 2.13.1 with SVG sanitization on, the default setting. CVSS rates it 5.3 (medium); no vendor rating is given. Fixed in 2.13.2.
- 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 2.13.2
- 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 self-hosted web application for PDF operations, is affected in versions from 2.13.1 up to (but not including) 2.13.2, specifically its SVG-to-PDF conversion endpoint. An attacker can craft an SVG file that causes the server to read and embed certain image files from its own filesystem into the returned PDF, exposing those local image contents (such as PNG, JPG, GIF, or SVG files) to the attacker.
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. From 2.13.1 until 2.13.2, the POST /api/v1/convert/svg/pdf endpoint renders attacker-supplied SVG through Apache Batik, and a scheme-less root-relative image reference bypasses SvgSanitizer.isExternalUrl() before Batik resolves it against the file:///input.svg document base as a same-origin local file. The convert() and addSvgAsPage() paths in app/core/src/main/java/stirling/software/SPDF/utils/SvgToPdf.java can then render image-decodable server files into the returned PDF when sanitization is enabled, including without authentication on login-disabled deployments or with non-admin access when login is enabled. The issue discloses PNG, JPG, GIF, or SVG content and provides an existence oracle only for image-decodable paths; plain text, binary files, directories, XInclude text, external entities, explicit file URLs, and tested HTTP references are not disclosed through this mechanism. This issue is fixed in version 2.13.2.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- Stirling-Tools Stirling-PDF
From 2.13.1 · fixed in 2.13.2
References 4
GitHub · Stirling-Tools/Stirling-PDF
Questions about CVE-2026-119342
What does this mean?
Files on the server that Batik can decode as images (PNG, JPG, GIF, or SVG) can be rendered into the PDF that Stirling-PDF returns, so a server-side local file can be read. The bug also reveals whether certain image paths exist on the server.Source: github.com
Am I affected, and how do I check?
Stirling-PDF versions from 2.13.1 up to, but not including, 2.13.2 are affected, in the default configuration where SVG sanitization is enabled (disableSanitize=false). To check a deployment, look at the installed Stirling-PDF version and at whether disableSanitize is set to true.Source: github.com
What should I do about it?
Upgrade Stirling-PDF to 2.13.2 or later, the version where the affected range ends.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