CVE-2026-33437

CVE-2026-33437 is a stored XSS in Stirling-PDF's 'Get Info' feature. When you use this feature to extract and display PDF metadata — fields like author, title, creator application, and creation date — the values are inserted into the DOM using innerHTML without any sanitization. A malicious PDF can contain JavaScript payloads in any of these metadata fields; when processed through Get Info, the payload executes in the context of the user's session. The underlying issue is that file-derived data occupies a blind spot in how many developers think about input trust. Data arriving via HTTP parameters gets sanitized; data extracted from an uploaded file is often treated as inherently safe. But a PDF uploaded by a user IS user input — it's just wrapped in multipart/form-data instead of a query string. This mental model gap is so natural it's nearly invisible during code review, which is why this vulnerability class recurs so systematically across document processing tools. The fix is straightforward: replace innerHTML with textContent or use a templating library with auto-escaping. However, patching this one call doesn't address the deeper problem — the PDF parsing layer still treats metadata as trusted content, and any future feature that renders file-derived strings carries the same risk. What makes this vulnerability more serious than a typical stored XSS is the deployment profile. Stirling-PDF is a self-hosted utility run by sysadmins, IT departments, legal teams, and power users — precisely the users whose browser sessions have privileged access to internal tooling, admin panels, and VPN portals. A payload executed through this vulnerability can potentially reach tokens for Confluence, Jira, internal admin interfaces, and other high-value targets. The users most likely to process untrusted PDFs are also the users most likely to receive them from external parties: legal teams reviewing contracts, auditors examining vendor submissions, IT staff processing documentation. If you're running Stirling-PDF, treat any PDF from an untrusted source as potentially hostile. The fix in version 2.0.0 addresses the rendering layer, but the broader lesson is that file parsing libraries return untyped strings with no indication of which values require escaping before rendering. This API design choice — made by PDF libraries across the ecosystem — places the security decision on every downstream developer, where it predictably gets missed. Consider this vulnerability a signal to audit any feature that renders file-derived content in your own applications, regardless of whether the file came from a 'trusted' internal source.

Reviewed through automated stages and approved by a human before publication.