CVE-2026-93653: Poppler Splash Backend DOS Vulnerability

CVE-2026-93653 Overview

CVE-2026-93653 is a denial of service vulnerability in Poppler's Splash rendering backend. A crafted PDF containing tiling-pattern geometry near the int32 boundary can cause SplashOutputDev::tilingPatternFill to compute an attacker-controlled repeat count. This value drives an extended loop inside the pattern-fill scanline routine without a corresponding memory allocation. Any application that renders untrusted PDFs through Poppler's Splash backend is affected. The weakness is tracked as [CWE-606: Unchecked Input for Loop Condition].

Critical Impact
Rendering a malicious PDF causes the process to consume 100% CPU for an attacker-controlled duration, disrupting document viewers and PDF processing services.

Affected Products

Poppler (Splash output backend)
Linux distributions bundling vulnerable Poppler builds (see Red Hat CVE-2026-93653)
Applications that render PDFs via Poppler, including document viewers and server-side conversion tools

Discovery Timeline

2026-09-18 - CVE-2026-93653 published to NVD
2026-09-18 - Last updated in NVD database

Technical Details for CVE-2026-93653

Vulnerability Analysis

The flaw resides in Poppler's Splash backend function SplashOutputDev::tilingPatternFill. The function computes how many times a tile must repeat to cover the target fill area. When a PDF supplies tiling-pattern geometry approaching the signed 32-bit integer boundary, the repeat count expands to an attacker-controlled magnitude. The pattern-fill scanline routine then loops for that count. No corresponding memory allocation occurs, so the process does not fail with an allocation error. Instead, it enters an extended CPU-bound loop and stalls the rendering thread.

Root Cause

The root cause is unchecked input driving a loop bound. The function derives loop iteration counts from PDF-supplied geometry without validating that the resulting repeat count is bounded. Because the arithmetic stays within the int32 range, prior overflow checks do not trigger. The loop then executes to completion, honoring attacker-controlled values.

Attack Vector

Exploitation requires an application to open a crafted PDF and render it through the Splash backend. User interaction is required, consistent with the local attack vector characterization. The impact is limited to availability. Confidentiality and integrity are not affected. Server-side services that automate PDF rendering (thumbnail generation, conversion pipelines, print spoolers) can amplify the effect because a single malicious document can occupy a worker process for an extended period.

No verified public code or proof-of-concept is available at time of publication. See the Red Hat Bug Report #2537005 for upstream tracking.

Detection Methods for CVE-2026-93653

Indicators of Compromise

Renderer processes such as pdftoppm, pdftocairo, evince, or okular sustaining 100% CPU on a single core after opening a PDF
PDF files whose tiling-pattern dictionaries contain unusually large BBox or XStep/YStep values approaching INT32_MAX
Server-side conversion workers exceeding expected per-document processing time budgets

Detection Strategies

Static PDF inspection for tiling pattern resources with geometry values approaching signed 32-bit boundaries
Process-level watchdogs that terminate Poppler-based renderers exceeding CPU or wall-clock thresholds
Correlate high CPU utilization events with recent PDF open events in endpoint telemetry

Monitoring Recommendations

Track CPU time per rendering job in PDF processing pipelines and alert on outliers
Log PDF file hashes processed by conversion services to support post-incident triage
Monitor for repeated submissions of similarly structured PDFs from the same source, indicating deliberate abuse

How to Mitigate CVE-2026-93653

Immediate Actions Required

Apply distribution updates for Poppler once vendor patches are published; consult Red Hat CVE-2026-93653 for status
Enforce CPU and wall-clock limits on any process that renders untrusted PDFs
Restrict PDF rendering workers to sandboxed accounts with resource controls

Patch Information

Upstream Poppler and downstream distributions are tracking the issue through Red Hat Bug Report #2537005. Apply vendor-supplied updates as they become available. Until patches ship, treat the mitigations below as compensating controls.

Workarounds

Run PDF renderers under systemd unit files with CPUQuota= and RuntimeMaxSec= to bound execution
Use ulimit -t or prlimit --cpu to cap CPU seconds for command-line tools such as pdftoppm
Route untrusted PDFs through a sandbox (containers, bwrap, or firejail) so a stalled renderer cannot affect the host
Where feasible, switch server-side rendering to an alternate backend and reject documents that fail a pre-processing timeout

bash

# Configuration example: enforce CPU and time limits on a PDF rendering worker
systemd-run --scope \
  -p CPUQuota=50% \
  -p RuntimeMaxSec=15 \
  -p MemoryMax=512M \
  pdftoppm -r 150 /input/untrusted.pdf /output/page

# Shell-level fallback using prlimit
prlimit --cpu=10 --as=536870912 -- \
  pdftocairo -pdf /input/untrusted.pdf /output/rendered.pdf