CVE-2026-22691: 
Python vulnerability analysis and mitigation

CVE-2026-22691 is a denial-of-service vulnerability in pypdf, a free and open-source pure-Python PDF library, caused by inefficient handling of malformed startxref entries during cross-reference table rebuilding. An unauthenticated attacker can craft a PDF file with invalid startxref entries and excessive whitespace characters to trigger abnormally long processing times. Only versions prior to 6.6.0 are affected, and only when using the default non-strict reading mode. The vulnerability was disclosed on January 9, 2026, with a CVSS v3.1 score of 5.3 (Medium) and a CVSS v4.0 score of 2.7 (Low) (Github Advisory).

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-1333 (Inefficient Regular Expression Complexity). When pypdf encounters a broken startxref table in non-strict mode, it attempts to rebuild the cross-reference table using a regex-based search (re.finditer) over the entire file content. PDF files containing large amounts of whitespace characters cause this regex to exhibit exponential worst-case complexity, consuming excessive CPU cycles. The fix in PR #3594 replaced the regex-based approach with a manual string.find()-based search, which performs significantly better in pathological cases (Github Advisory, Patch PR).

Successful exploitation results in a partial denial-of-service condition limited to availability — there is no impact on confidentiality or integrity. An attacker can cause applications that process user-supplied PDFs using pypdf in non-strict mode to consume excessive CPU resources and become unresponsive or severely degraded for the duration of processing the malicious file. The impact is scoped to the vulnerable system itself, with no lateral movement potential or data exposure risk (Github Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation as of the time of disclosure. The vulnerability has an EPSS score of approximately 0.017% (4th percentile), indicating a low probability of exploitation in the near term. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires only the ability to supply a crafted PDF file to an application using pypdf in non-strict mode, with no authentication or special privileges needed (Github Advisory).

1. Craft malicious PDF: Create a PDF file with an invalid or malformed startxref entry and pad the file body with a large number of whitespace characters (spaces, tabs, newlines) to maximize regex backtracking during cross-reference table rebuilding.
2. Deliver the file: Submit the crafted PDF to any application or service that uses pypdf (versions < 6.6.0) to process user-supplied PDF files in the default non-strict reading mode (e.g., a web upload endpoint, document processing pipeline).
3. Trigger parsing: The application calls PdfReader("malicious.pdf") (without strict=True), causing pypdf to detect the broken startxref and invoke _rebuild_xref_table().
4. Exhaust CPU: The regex re.finditer(rb"[\r\n \t][ \t]*(\d+)[ \t]+(\d+)[ \t]+obj", file_data) processes the whitespace-heavy content with exponential complexity, causing the process to consume excessive CPU and stall, degrading service availability for legitimate users (Github Advisory, Patch PR).

• Process: Sustained high CPU usage by a Python process handling PDF parsing; the process may appear hung or unresponsive for extended periods while processing a single PDF file.
• Logs: Application logs showing unusually long processing times or timeouts for PDF read operations; errors or warnings from pypdf related to broken startxref or cross-reference table rebuilding in non-strict mode.
• File System: Presence of PDF files with anomalously large file sizes dominated by whitespace characters and malformed or missing startxref entries, submitted via upload endpoints or found in processing queues.

Upgrade pypdf to version 6.6.0 or later, which replaces the vulnerable regex-based cross-reference table rebuilding with an efficient string.find()-based approach (pypdf Release). If immediate patching is not feasible, switch to strict reading mode as a workaround: use PdfReader("file.pdf", strict=True) instead of the default non-strict mode, or PdfWriter(clone_from=PdfReader("file.pdf", strict=True)) for write operations (Github Advisory). Additionally, consider implementing input validation to reject PDFs with suspicious characteristics (e.g., excessive whitespace or missing startxref) before passing them to pypdf.