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 INT_MAX (~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 surface_width * repeatX (or surface_height * repeatY) would overflow an int; it does not bound repeatX/repeatY to a sane value when the product happens to fit under INT_MAX, 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.