CVE-2022-28368

Vulnerability

Dompdf version 1.2.1 contains a remote code execution vulnerability in the handling of @font-face CSS rules. When processing an HTML document that includes a @font-face declaration, the parser passes the src:url() value directly to a font loading routine without adequate validation. An attacker can supply a url() that points to a .php file on the same server. Because dompdf uses fopen() with wrappers enabled, the PHP file is executed by the PHP engine before the result is loaded as a font. The vulnerability is present in dompdf versions prior to the fix committed in pull request #2808 [1][2].

Exploitation

The attacker must be able to upload or serve an HTML file that is processed by a vulnerable dompdf installation (version 1.2.1). No authentication is required if the application accepts user-supplied HTML content for PDF generation. The exploit involves crafting an HTML document with a @font-face block where the src:url field references a .php file (e.g., src: url("/path/to/exploit.php");). When dompdf parses this CSS, it attempts to fetch the font via PHP's file functions; if the referenced file is a PHP script, it is executed by the server's PHP interpreter, and the output (which may be arbitrary) is embedded into the generated PDF. The attacker must control a .php file on the same filesystem as the target application, or have access to a file upload feature that places a .php file reachable via the web root [1][2].

Impact

Successful exploitation results in remote code execution at the privilege level of the web server process. The attacker can execute arbitrary PHP code, which may lead to full compromise of the application and the underlying server, including data exfiltration, file manipulation, or lateral movement within the network. The vulnerability has been assigned a CVSS v3.1 score of 9.8 (Critical) due to low attack complexity, network attack vector, and no required privileges or user interaction [2].

Mitigation

The dompdf project addressed the vulnerability in pull request #2808, which ensures that the file extension of the font source matches the expected font type (ttf, otf, woff, etc.) before loading. The fix was merged, and a patched version (1.2.2) was released on 2022-04-15 via Packagist [3]. Users must upgrade to dompdf 1.2.2 or later. As a temporary workaround, administrators can disable PHP execution in directories where attacker-controlled files might be placed or restrict the open_basedir PHP directive to prevent access to scripts outside the intended font directory. The vulnerability is not currently listed in CISA's Known Exploited Vulnerabilities catalog [4].