CVE-2026-93653: Poppler: poppler: unbounded cpu loop in splashoutputdev::tilingpatternfill via unvalidated tiling-pattern repeat count (denial of service)
A denial of service flaw was found in Poppler's Splash backend. A crafted PDF with tiling-pattern geometry approaching the int32 boundary can cause SplashOutputDev::tilingPatternFill to compute an attacker-controlled repeat count that drives an excessively long loop in the pattern-fill scanline routine, without a corresponding memory allocation. An attacker could exploit this by supplying a malicious PDF to an application that renders it via Poppler's Splash backend, causing the rendering process to consume 100% CPU for an attacker-controlled, extended duration.
Other sources
A flaw was found in Poppler's Splash backend. In SplashOutputDev::tilingPatternFill (poppler/SplashOutputDev.cc), when a PDF's tiling pattern geometry (fill rectangle and step) drives the computed repeat count for the pattern-fill loop, the raw, PDF-controlled span (x1 - x0 / y1 - y0) is substituted directly into repeatX/repeatY whenever it exceeds the value derived from the (possibly overflowed) surface dimensions. This allows an attacker-supplied PDF to set repeatX/repeatY to a value bounded only by INTMAX (~2^31), which then drives an unconditional, unclipped loop in the tilingBitmapSrc scanline callback that executes once per output scanline. Because the source tile bitmap itself remains tiny, memory usage stays flat while the process consumes 100% CPU for an extended period, resulting in denial of service. This is a residual, distinct consequence of the same tilingPatternFill arithmetic defect addressed by CVE-2026-10118: the checkedMultiply() guard added by that fix only rejects requests where surfacewidth repeatX (or surfaceheight repeatY) would overflow an int; it does not bound repeatX/repeatY to a sane value when the product happens to fit under INTMAX, which is exactly the case exploited here. Confirmed reproducible on poppler 26.04.0, 26.06.0 (the CVE-2026-10118 fixed release), 26.08.0, and current master via an ~820-byte crafted PDF; verified against upstream source for all three references. Any application using Poppler's Splash backend to render untrusted PDFs (pdftoppm, document preview, mail-gateway attachment scanning, OCR pipelines) can be pinned to one CPU core per submitted file.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
popplerto a version that resolves this vulnerability.Fixed in 26.04.0 - Upgrade
Upgrade
popplerto a version that resolves this vulnerability.Fixed in 26.06.0 - Upgrade
Upgrade
popplerto a version that resolves this vulnerability.Fixed in 26.08.0 - Compensating control
For applications using Poppler's Splash backend (e.g., pdftoppm, document preview, mail-gateway attachment scanning, OCR pipelines), pin the rendering workload to one CPU core per submitted file to limit CPU-denial-of-service impact from crafted PDFs.
Event History
Frequently Asked Questions
Which environments are exposed to this denial of service?
Applications that render attacker-supplied PDFs through Poppler's Splash backend are exposed. The impact is on the rendering process, which can consume 100% CPU for an attacker-controlled extended duration.
What does exploitation require?
An attacker needs to supply a crafted PDF and have a user or application render it using the affected Splash backend. The PDF uses tiling-pattern geometry near the int32 boundary to drive an excessively large repeat count.
Is memory exhaustion required for the attack?
No. The issue causes an excessively long, unconditional scanline loop without a corresponding memory allocation, so the primary effect is CPU consumption rather than memory exhaustion.