CVE-2026-113790: Uncontrolled Resource Consumption in pypdf Container Parsing

The Python PDF manipulation library pypdf is susceptible to uncontrolled resource consumption (CWE-400 / CWE-770) during PDF container deserialization. Prior to version 6.21.0, the library processed primitive PDF container structures sequentially without verifying upper bounds on element counts or enforcing a global token budget.

PDF documents structure raw metadata and stream data into three core collection mechanisms: Arrays, Dictionaries, and Content Streams. When parsing these entities, pypdf eagerly allocated Python objects for every token encountered within stream boundaries. An attacker can construct a compact, highly compressed PDF containing millions of small elements to induce memory exhaustion or execution loops.

This flaw impacts web applications, background document pipelines, and API services that ingest untrusted PDF uploads using vulnerable pypdf releases.

The root cause resides in the token parsing logic implemented within ArrayObject.read_from_stream, DictionaryObject.read_from_stream, and ContentStream._parse_content_stream. The library assumed stream content was bounded implicitly by file length or decompressed stream limits.

During stream processing, the parser reads consecutive tokens and instantiates corresponding Python wrapper types (NumberObject, NameObject, BooleanObject, NullObject). Because Python object creation incurs per-instance memory overhead, dense token streams demand memory disproportionate to file size on disk.

> [!NOTE] > A PDF array containing 1,000,000 integer tokens requires minimal stream storage, but causes pypdf to allocate hundreds of megabytes of Python heap memory during deserialization.

Additionally, generic exception handlers inside structural parsing functions previously caught and suppressed underlying security exceptions. If a sub-routine encountered a parsing boundary error, the container parser suppressed the signal and continued consumption.

In commit 18bd2981a74479483a0b9507602c58a63d6c9b12 (Pull Request #4218), maintainers implemented global token tracking and safety thresholds in pypdf/_configuration.py and pypdf/generic/_data_structures.py.

The patch introduces explicit collection caps alongside a shared, mutable budget context (StreamParsingBudget):

# pypdf/_configuration.py snippet
array_maximum_element_count: int = 100_000
dictionary_maximum_element_count: int = 100_000
stream_parsing_work_maximum_count: int = 2_000_000

The ArrayObject.read_from_stream method was modified to check remaining quotas before appending new elements:

# Patch diff in ArrayObject._check_limits
@staticmethod
def _check_limits(*, remaining_elements: int, parsing_budget: Optional[StreamParsingBudget]) -> int:
    remaining_elements -= 1
    if remaining_elements < 0:
        raise LimitReachedError("Reached maximum array element count.")
    if parsing_budget is not None:
        parsing_budget.remaining_budget -= 1
        if parsing_budget.remaining_budget < 0:
            raise LimitReachedError("Reached maximum number of tokens.")
    return remaining_elements

When LimitReachedError is raised, container parsers now propagate the exception directly rather than catching it in general exception handling clauses.

Exploitation requires sending a tailored PDF document to an application that invokes parsing methods on untrusted input. Authentication requirements depend entirely on the target application exposure.

An attacker constructs a document containing deeply nested collection structures or repetition patterns. For instance, a stream defining an array with millions of null tokens [ null null ... null ] causes pre-6.21.0 parsers to enter a long execution loop while repeatedly increasing heap memory usage.

%PDF-1.7
1 0 obj
<< /Type /Catalog /Pages 2 0 R >>
endobj
2 0 obj
<< /Type /Pages /Count 1 /Kids [3 0 R] >>
endobj
3 0 obj
<< /Type /Page /Parent 2 0 R /Contents 4 0 R >>
endobj
4 0 obj
<< /Length 50000 >>
stream
[ 0 0 0 0 ... <repeated 1,000,000 times> ... 0 ]
endstream
endobj

When the application attempts to inspect or extract text from page content streams, the thread parsing the stream exhausts available memory, leading to an Out-Of-Memory (OOM) process termination.

The security impact is restricted to application availability. Unauthenticated users can trigger service disruptions by uploading crafted PDF documents to public endpoints.

Because Python handles memory allocation at the process level, exhaustion in a multi-threaded web worker (such as Gunicorn or uWSGI workers) results in worker termination by system kernel OOM killers, causing service degradation or total application outage.

CVSS v4.0 evaluates this issue with a base score of 6.0 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N). No confidentiality or integrity violations occur, and execution context boundaries prevent remote code execution through this bug class.

The primary remediation step is upgrading the pypdf dependency to version 6.21.0 or higher.

For applications requiring custom threshold definitions when handling untrusted documents, parameters can be customized dynamically using apply_configuration:

from pypdf import apply_configuration, PdfReader
from pypdf.errors import LimitReachedError
 
# Configure custom strict parsing limits
with apply_configuration(
    array_maximum_element_count=10_000,
    dictionary_maximum_element_count=10_000,
    stream_parsing_work_maximum_count=500_000
):
    try:
        reader = PdfReader("untrusted_document.pdf")
        text = reader.pages[0].extract_text()
    except LimitReachedError:
        # Gracefully drop or reject malformed inputs
        raise ValueError("Uploaded file exceeded maximum parsing limits")

Additionally, processing untrusted uploads inside isolated container environments with resource memory limits prevents host-wide Denial of Service.