CVE-2026-119206: 
Python vulnerability analysis and mitigation

CVE-2026-119206 is an algorithmic complexity (denial-of-service) vulnerability in pypdf, a free and open-source pure-Python PDF library. Prior to version 6.21.3, pypdf can take excessive time to retrieve page labels from a crafted PDF containing a flat page-label number tree with many ranges, due to an O(pages × label_ranges) scanning pattern in the page_labels property. All pypdf versions before 6.21.3 are affected. The vulnerability was disclosed on October 29, 2026, and carries a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, Feedly).

The root cause is an uncontrolled resource consumption flaw (CWE-400) in the page_labels property of pypdf's _page_labels.py module. The property calls index2label for every page, and each call scans the /Nums array from the beginning, causing total work to grow proportionally to the product of the page count and the number of label ranges. For example, a 5,000-page document with 2,500 label ranges took approximately 1.32 seconds to process before the fix, compared to 9 milliseconds after. An attacker can exploit this by crafting a PDF with a large flat /Nums array and many label ranges, then submitting it to any application that accesses the page_labels property (GitHub Advisory, GitHub PR #4251).

Successful exploitation causes excessive CPU consumption and long runtimes in any application that processes the page_labels property on attacker-supplied PDFs, effectively rendering the affected service unresponsive or severely degraded (denial of service). There is no confidentiality or integrity impact — only availability is affected. Applications that automatically process uploaded or received PDF files without sanitization are at greatest risk (GitHub Advisory, Feedly).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The EPSS score is 0.0, indicating very low current exploitation probability, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires user interaction in the sense that a passive user or automated pipeline must process the crafted PDF, but no authentication or special privileges are required from the attacker's side (Feedly).

1. Craft a malicious PDF: Create a PDF file with a /PageLabels dictionary containing a flat /Nums array with a large number of label ranges (e.g., thousands of key-value pairs) and a high page count, maximizing the O(pages × ranges) processing cost.
2. Identify a target: Find an application or service that uses pypdf (versions < 6.21.3) and accesses the page_labels property on user-supplied PDFs — such as document converters, PDF metadata extractors, or web upload endpoints.
3. Submit the crafted PDF: Upload or send the malicious PDF to the target application through any available input channel (file upload form, API endpoint, email attachment processor, etc.).
4. Trigger denial of service: When the application calls reader.page_labels, the quadratic scanning loop consumes excessive CPU time, causing the process to hang or become unresponsive, potentially exhausting server resources if multiple requests are sent concurrently (GitHub Advisory, GitHub PR #4251).

• Process: Python processes consuming abnormally high CPU for extended periods while processing PDF files; worker threads or processes stuck in pypdf's _page_labels.py code.
• Logs: Application logs showing unusually long response times or timeouts specifically when processing PDF files; repeated processing of the same or similar PDF files from the same source.
• File System: Presence of crafted PDF files with abnormally large /PageLabels /Nums arrays (detectable via PDF inspection tools); PDFs with page counts and label range counts in the thousands.
• Network: High volume of PDF upload requests from a single source IP, particularly if each request causes elevated CPU usage on the server (GitHub Advisory).

Upgrade pypdf to version 6.21.3 or later, which fixes the issue by walking the flat /Nums array once for all pages instead of rescanning from the beginning for each page (GitHub Release). For users who cannot upgrade immediately, the changes from PR #4251 can be applied manually as a workaround (GitHub PR #4251). Additionally, consider implementing file size and processing time limits for PDF inputs in applications that process user-supplied files.