CVE-2026-59943 in Dompdf
Summary
by MITRE • 07/29/2026
Dompdf is an HTML to PDF converter for PHP. In versions 3.15 and prior, if a malicious actor can supply unrestricted content for rendering by Dompdf they can utilize the SVG rendering functionality to leak filesystem information when rendering PDF files using image references within a data-URI encoded SVG document. Using an <image> element inside a data-URI embedded SVG, an attacker can attempt to embed other files via the href or xlink:href attributes. When processing a file that does not exist (e.g. file:///DOESNOTEXIST), dompdf behaves differently than it does when accessing a file or directory that actually exists on the filesystem. This issue has been fixed in version 3.16.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/29/2026
The vulnerability in Dompdf versions 3.15 and prior represents a critical information disclosure flaw that emerges from improper handling of SVG rendering functionality within the HTML to PDF conversion process. This weakness specifically manifests when attackers can inject unrestricted content into the rendering pipeline, enabling them to exploit the SVG image element's ability to reference external resources through data-URI encoded documents. The vulnerability operates at the intersection of web application security and document processing, where the library's failure to properly sanitize or restrict file access during SVG rendering creates an attack surface that can be leveraged for unauthorized filesystem enumeration.
The technical mechanism behind this vulnerability involves the differential behavior of Dompdf when processing non-existent versus existing filesystem references within SVG documents. When an attacker crafts an SVG element using the <image> tag with href or xlink:href attributes pointing to file system locations, the library exhibits distinct response patterns depending on whether the referenced resource exists. This behavioral difference creates a side-channel attack vector where attackers can systematically test various filesystem paths and observe the varying responses from the rendering engine to determine which files or directories are accessible on the server. The vulnerability specifically affects the data-URI encoded SVG processing path, where external file references are resolved without proper access controls or sanitization.
The operational impact of this vulnerability extends beyond simple information disclosure, as it enables attackers to perform reconnaissance activities that could lead to more severe compromises. An attacker could potentially enumerate system files, identify sensitive directories, or discover the presence of configuration files and other resources that might not be directly accessible through normal web application interfaces. This filesystem enumeration capability aligns with attack patterns documented in the ATT&CK framework under reconnaissance techniques, specifically targeting system information discovery and credential access. The vulnerability affects both file and directory enumeration scenarios, making it particularly dangerous for applications that process untrusted user input through Dompdf's rendering functionality.
This vulnerability maps directly to CWE-20: Improper Input Validation and CWE-502: Deserialization of Untrusted Data, as it stems from inadequate validation of external references within SVG content and the unsafe processing of potentially malicious data. The attack vector primarily exploits the trust model that exists between the rendering engine and filesystem access, where legitimate SVG functionality is abused to gain unauthorized access to system resources. Organizations using Dompdf in applications that accept user-generated content or allow arbitrary HTML input are particularly vulnerable, as they provide attackers with direct pathways to exploit this information disclosure mechanism. The fix implemented in version 3.16 addresses the core issue through enhanced input validation and proper restriction of filesystem access during SVG processing, aligning with security best practices outlined in OWASP's secure coding guidelines.
The remediation approach required for this vulnerability involves upgrading to Dompdf version 3.16 or later, which implements proper sanitization of file references within SVG data-URIs and ensures consistent behavior when accessing non-existent filesystem resources. Organizations should also implement additional protective measures such as restricting the ability to process external resource references in SVG content, implementing proper input validation for all user-supplied content, and monitoring for unusual filesystem access patterns that might indicate exploitation attempts. Security teams should consider this vulnerability as part of broader application security testing procedures, particularly when evaluating document processing libraries that handle untrusted input, and ensure that similar issues are not present in other components of the application stack that might exhibit similar behaviors with file system access or external resource resolution.