CVE-2023-24813
Dompdf Project Dompdf 2.0.2
Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2023-24813 is a critical-severity Interpretation Conflict (CWE-436) vulnerability in Dompdf Project Dompdf. Its CVSS base score is 10.0 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 17% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Dompdf, an HTML-to-PDF converter library written in PHP, contains a protocol-handling flaw that stems from inconsistent attribute parsing between its own image-tag logic and the downstream php-svg-lib SVG parser. Dompdf honors xlink:href on image elements even when an empty href is also present, while php-svg-lib later respects the href attribute; this mismatch lets an attacker bypass intended restrictions and supply an SVG containing arbitrary URL schemes.
An unauthenticated remote attacker who can cause Dompdf to process a crafted SVG file can therefore trigger requests to arbitrary protocols. On PHP versions prior to 8.0.0 the same path reaches arbitrary unserialize, enabling at minimum file deletion and, depending on available classes, potential remote code execution. The CVSS 10.0 score reflects the combination of network reachability, lack of privileges or user interaction, and full impact on confidentiality, integrity, and availability.
The project’s security advisory and the referenced commit 95009ea98 state that the issue is resolved in release 2.0.3; users are advised to upgrade, as no workarounds are provided. The associated EPSS score has remained flat at 0.0932 with no material post-disclosure rise.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-0628
Vulnerability Data
Dompdf is an HTML to PDF converter written in php. Due to the difference in the attribute parser of Dompdf and php-svg-lib, an attacker can still call arbitrary URLs with arbitrary protocols. Dompdf parses the href attribute of `image` tags…
more
and respects `xlink:href` even if `href` is specified. However, php-svg-lib, which is later used to parse the svg file, parses the href attribute. Since `href` is respected if both `xlink:href` and `href` is specified, it's possible to bypass the protection on the Dompdf side by providing an empty `xlink:href` attribute. An attacker can exploit the vulnerability to call arbitrary URLs with arbitrary protocols if they provide an SVG file to the Dompdf. In PHP versions before 8.0.0, it leads to arbitrary unserialize, which will lead, at the very least, to arbitrary file deletion and might lead to remote code execution, depending on available classes. This vulnerability has been addressed in commit `95009ea98` which has been included in release version 2.0.3. Users are advised to upgrade. There are no known workarounds for this vulnerability.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly reduce the chance of introducing parser or state-machine inconsistencies.
Correlating logs from multiple products can surface discrepancies caused by interpretation conflicts.
Runtime monitoring of software behavior can detect adverse outcomes stemming from differing interpretations.
Supplier risk assessments can identify products whose differing interpretations create systemic exposure.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect and correct cases where one component misinterprets another’s state or messages.
Secure development lifecycle can require consistent interface contracts and canonicalization rules that reduce interpretation conflicts between components.
Explicit application security requirements can mandate unambiguous protocol and data-format specifications that prevent divergent interpretations.
Secure architecture principles include well-defined component boundaries and shared data models that limit conflicting state perceptions.
Secure coding standards can enforce canonical input handling and strict protocol compliance to avoid misinterpretation between products.