CVE-2026-59200: 
Python vulnerability analysis and mitigation

CVE-2026-59200 is a decompression bomb denial-of-service vulnerability in Pillow, the Python imaging library. The flaw exists in PdfParser.PdfStream.decode() within PIL/PdfParser.py, where zlib.decompress() is called with bufsize set to the PDF stream's Length field without any upper bound on the decompressed output size. This allows a crafted FlateDecode-compressed PDF stream to exhaust all available server memory from a small (~950 KB) file. Affected versions span from 5.1.0 through 12.2.x; the issue is fixed in version 12.3.0. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified under CWE-400 (Uncontrolled Resource Consumption), CWE-770 (Allocation of Resources Without Limits or Throttling), and CWE-409 (Improper Handling of Highly Compressed Data). In the vulnerable code path, PdfStream.decode() reads the DL or Length field from the PDF stream dictionary and passes it directly as the bufsize hint to zlib.decompress(). Critically, Python's zlib.decompress() treats bufsize as an initial output buffer hint — not a maximum size cap — meaning the function will allocate as much memory as needed to fully decompress the stream regardless of the hint value. An attacker can craft a PDF with a FlateDecode stream that compresses ~1 GB of null bytes into ~950 KB, achieving a ~1,028× expansion ratio; the fix in PR #9718 replaces the unbounded zlib.decompress() call with zlib.decompressobj().decompress(buf, max_length) defaulting to ImageFile.SAFEBLOCK, raising a ValueError if the decompressed output exceeds the limit (GitHub Advisory, Fix Commit).

Successful exploitation causes a denial-of-service condition: an unauthenticated attacker who can submit a PDF file for processing can exhaust all available server memory, resulting in OOM (out-of-memory) process termination or severe service degradation affecting all concurrent users of the application. The impact is limited to availability — there is no confidentiality or integrity impact. Any application using PIL.PdfParser.PdfParser to read untrusted PDF files is affected, including web services, document processing pipelines, and batch conversion tools (GitHub Advisory).

A self-contained, runnable proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating memory exhaustion by constructing a minimal valid PDF with a FlateDecode bomb and triggering the vulnerable decode() path — no network access or external victim system is required (GitHub Advisory). The vulnerability is automatable (no user interaction or privileges required) and exploitable over the network with low attack complexity. As of the time of reporting, there is no evidence of active in-the-wild exploitation or threat actor attribution. The EPSS score is approximately 0.0035 (0.35%), and the vulnerability is not listed in the CISA KEV catalog (Feedly).

1. Craft the malicious PDF: Using Python, create a minimal but valid PDF file containing a FlateDecode-compressed stream. Compress a large block of null bytes (e.g., 100 MB–1 GB) using zlib.compress() at maximum compression level, yielding a ~950 KB compressed payload with a ~1,028× expansion ratio.
2. Set the PDF Length field: In the PDF stream dictionary, set the Length field to the size of the compressed data (not the decompressed size). This avoids triggering format validation while still causing unbounded decompression.
3. Deliver the PDF to the target: Submit the crafted PDF to any application endpoint that uses PIL.PdfParser.PdfParser to parse untrusted PDF files (e.g., a file upload endpoint, document conversion API, or image processing service).
4. Trigger the vulnerable code path: When the application opens the PDF with PdfParser.PdfParser(filename) and accesses a compressed stream object, PdfStream.decode() is called, which invokes zlib.decompress(self.buf, bufsize=int(expected_length)) without any size cap.
5. Achieve denial of service: The decompression expands the ~950 KB file into ~1 GB of memory allocation, exhausting available RAM and causing OOM termination of the server process or severe degradation affecting all concurrent users (GitHub Advisory).

• Network: Repeated upload requests delivering small PDF files (~10 KB–1 MB) to document processing or image conversion endpoints; unusual spikes in inbound traffic to PDF-handling services.
• Process/Memory: Sudden, rapid memory exhaustion in Python processes running Pillow-based applications; OOM killer events in system logs (dmesg, /var/log/syslog) referencing the application process; process crashes or restarts correlated with PDF file submissions.
• Logs: Application error logs showing MemoryError or OOM-related exceptions originating from PIL/PdfParser.py; web server access logs showing POST requests with small PDF payloads followed by application downtime or 5xx errors.
• File System: Presence of small (~10 KB–1 MB) PDF files in upload directories that, when inspected, contain FlateDecode streams with a Length field disproportionately small relative to the expected decompressed size (GitHub Advisory).

Upgrade Pillow to version 12.3.0 or later, which introduces a max_length parameter (defaulting to ImageFile.SAFEBLOCK) in PdfStream.decode() and raises a ValueError if the decompressed output exceeds the limit (Pillow Release 12.3.0, Fix Commit). If immediate patching is not possible, implement input validation to reject PDF files with suspiciously large Length fields in FlateDecode streams before passing them to Pillow, or restrict the file types and sources accepted by PDF-processing endpoints. SUSE has also issued security updates (SUSE-SU-2026:3084-1 and SUSE-SU-2026:3268-1) for affected distributions (Red Hat Bugzilla).

The vulnerability was reported by security researcher redyank and published via GitHub's security advisory process on July 7, 2026. SUSE issued two security update announcements (SUSE-SU-2026:3084-1 and SUSE-SU-2026:3268-1) addressing the issue in their distributions. Red Hat tracked the issue via Bugzilla with a high severity rating and a broad CC list of 56 users, indicating significant internal attention. Tenable added detection plugins (Nessus IDs 327748 and 330318) and Qualys added detection (ID 764247) shortly after disclosure, reflecting prompt uptake by the vulnerability management community (GitHub Advisory, Red Hat Bugzilla).