CVE-2026-102997: 
Python vulnerability analysis and mitigation

CVE-2026-102997 is a Denial of Service vulnerability in pypdf, a free and open-source pure-Python PDF library maintained by py-pdf. A crafted PDF containing a partially malformed /FlateDecode stream with padded data can force pypdf/filters.py to use inefficient byte-by-byte decompression while the recovery counter fails to advance for bytes that successfully decode, causing excessive CPU consumption and application unavailability. All versions prior to 6.18.1 are affected. The vulnerability was published on September 30, 2026, with a fix released on September 11, 2026 in version 6.18.1. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Red Hat).

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption), CWE-407 (Inefficient Algorithmic Complexity), and CWE-835 (Loop with Unreachable Exit Condition). The vulnerability exists in pypdf/filters.py within the decompress() function's FlateDecode recovery path: when a partially malformed stream with padded data (e.g., a GZIP-prefixed zlib stream) is processed, the library falls back to slow byte-by-byte decompression. The prior fix only incremented the recovery counter for bytes that failed to decode, meaning bytes that successfully decoded (as in padded/prefixed data) never advanced the counter, allowing the slow path to run indefinitely without triggering the recovery limit. The fix in PR #4073 restructures the counter to apply to all processed bytes, not just failed ones, and adds an upfront input-length check before processing each byte (GitHub Advisory, GitHub PR #4073, GitHub Commit).

Successful exploitation results in a Denial of Service affecting the availability of any application that uses pypdf to process user-supplied PDF files. An unauthenticated remote attacker can submit a specially crafted PDF over the network, causing the application to consume excessive CPU resources and become unresponsive or unavailable for the duration of processing. There is no impact on confidentiality or integrity. Applications that accept PDF uploads from untrusted sources — such as web services, document processing pipelines, or APIs — are most at risk (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to exist, and there is no evidence of active in-the-wild exploitation at this time. The vulnerability is network-exploitable with no authentication or user interaction required, and attack complexity is low, making it straightforward to trigger if an attacker can submit a PDF to a vulnerable application. The EPSS score is 0.0, reflecting the current absence of observed exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Red Hat).

1. Craft a malicious PDF: Create a PDF file containing a /FlateDecode-encoded stream where the compressed data is prefixed with non-zlib header bytes (e.g., a GZIP file header prepended to a valid zlib/flate stream), producing a partially malformed stream with padded data that triggers the byte-by-byte recovery path in pypdf.
2. Identify a target: Locate a web application, API, or service that accepts PDF file uploads and processes them using a vulnerable version of pypdf (< 6.18.1).
3. Submit the crafted PDF: Upload or submit the malicious PDF to the target application via its normal file upload or processing interface — no authentication is required if the endpoint is publicly accessible.
4. Trigger resource exhaustion: pypdf's decompress() function in filters.py enters the slow byte-by-byte decompression fallback; because the recovery counter only advances on failed bytes, successfully-decoded padded bytes never increment it, causing the loop to run for the full length of the stream without terminating.
5. Achieve Denial of Service: The application thread or process consumes excessive CPU for an extended period (previously observed at 28–33 seconds for test cases, scaling with stream size), rendering the application unresponsive or unavailable to legitimate users (GitHub Advisory, GitHub PR #4073).

• Network: Repeated HTTP requests submitting PDF files to upload or processing endpoints from the same or rotating source IPs; unusually large or malformed PDF payloads in transit.
• Process: Sustained high CPU utilization by the Python process handling PDF parsing; worker threads or processes hanging for extended periods (tens of seconds or more) on a single PDF file.
• Logs: Application logs showing long-running or timed-out PDF processing jobs; log entries from pypdf containing LimitReachedError or zlib decompression warnings from pypdf/filters.py (in patched versions); absence of completion log entries for submitted PDF processing tasks in unpatched versions.
• File System: Presence of crafted PDF files with GZIP-prefixed or otherwise padded /FlateDecode streams in upload directories or temporary processing folders.

The primary remediation is to upgrade pypdf to version 6.18.1 or later, which restructures the FlateDecode recovery counter to apply to all processed bytes and adds an upfront input-length limit check (GitHub Release). For deployments that cannot immediately upgrade, the maintainers recommend manually applying the changes from PR #4073 as a temporary workaround (GitHub Advisory). Additionally, consider implementing file size limits and input validation on PDF uploads, enforcing processing timeouts, and monitoring for unusual CPU consumption patterns in PDF-handling services.

Red Hat tracked the vulnerability via their security response process and opened a Bugzilla entry (Bug 2544294) with a high severity rating, indicating relevance to Red Hat product ecosystems that may bundle pypdf (Red Hat Bugzilla). The vulnerability was reported by security researcher geoffrey-diederichs and analyzed and patched by pypdf maintainer stefan6419846, who noted in the PR that the fix may be considered a breaking change for edge cases where non-standard GZIP-compressed streams are used in PDFs, though such usage violates the PDF specification (GitHub PR #4073). No significant broader media coverage or social media discussion has been identified at this time.