Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2022-28368 is a critical-severity Cross-site Scripting (CWE-79) vulnerability in Dompdf Project Dompdf. Its CVSS base score is 9.8 (Critical).
Operationally, ranked in the top 0.4% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) and SI-2 (Flaw Remediation) — see the control section below for these in your framework.
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 version 1.2.1 is affected by a remote code execution vulnerability that occurs when an attacker supplies an HTML document containing a CSS @font-face rule whose src:url field references a .php file. The library processes the supplied stylesheet without sufficient validation of font sources, allowing the referenced PHP content to be executed in the context of the Dompdf process.
An unauthenticated remote attacker can exploit the flaw simply by submitting a crafted HTML file to any application that uses Dompdf to render user-controlled documents. Successful exploitation grants arbitrary code execution on the server, with impacts equivalent to full confidentiality, integrity, and availability compromise as reflected in the CVSS 9.8 rating.
The project addressed the issue in commit 4c70e1025bcd9b7694b95dd552499bd83cd6141d and pull request 2808; administrators should upgrade to a patched release. Public exploit code has been published, and the vulnerability maintains an EPSS score near 0.88, indicating sustained exploitation interest after disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2022-1865
Vulnerability Data
Dompdf 1.2.1 allows remote code execution via a .php file in the src:url field of an @font-face Cascading Style Sheets (CSS) statement (within an HTML input file).
- CWE(s)
Related Threats
Likely ATT&CK TechniquesAI
Techniques this vulnerability likely enables, inferred from its description, weakness type, and attributed-actor tradecraft. Confidence is per-technique.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly requires validation of user-supplied HTML/CSS content to reject unsafe @font-face src:url references before Dompdf processes them.
Mandates timely application of the vendor patch (commit 4c70e10) that eliminates the unsafe font-source handling in Dompdf 1.2.1.
Requires mechanisms to detect and block malicious code execution attempts that result from the crafted CSS font rule.
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 target introduction of XSS via coding standards/testing (mostly), yet the single broad outcome leaves many specific neutralization vectors unaddressed (partial).
Patching and EOL replacement can remediate known XSS instances in libraries or frameworks (partial) but do nothing to enforce input neutralization in application code (none).
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.
Secure-coding testing and automated code-analysis tools are applied to detect improper neutralization of script-related content during web-page generation.
Knowledge exchange on emerging attack techniques and patches reduces the likelihood that cross-site scripting flaws remain unaddressed in deployed applications.
Operational indicators of compromise for web-application attacks can be incorporated into WAF or input-filtering rules, lowering the likelihood that unsanitized data reaches the browser.
Requiring language-specific secure-coding standards and automated scanning during the SDLC catches missing output encoding or improper neutralization of untrusted data before the software reaches production.
Secure-coding standards, SAST scans and removal of insecure code samples together eliminate the failure to neutralize script content that produces cross-site scripting flaws.
Webpage malware scanning and block-listing of known malicious sites reduce the likelihood that reflected or stored script payloads reach a user’s browser.