CVE-2026-59200

What it actually does

Pillow versions 5.1.0 through versions earlier than 12.3.0 can allocate excessive memory while decoding a crafted PDF. The vulnerable code path is PIL/PdfParser.py, where PdfParser.PdfStream.decode() passes the PDF stream Length value as the zlib.decompress() buffer size without enforcing a safe upper bound on decompressed output. An attacker can supply a small PDF containing a malicious FlateDecode stream whose metadata causes disproportionate decompression memory consumption, leading to process memory exhaustion and denial of service. The issue affects availability only; it does not directly provide confidentiality or integrity impact.

Why it matters to the business

Applications, APIs, background workers, document pipelines, or services that accept or process untrusted PDF files using Pillow can be crashed or made unavailable with a small malicious file. This can interrupt document upload workflows, image conversion jobs, PDF preview generation, automation pipelines, and any service where Pillow runs inside web-facing or queue-based processing paths. Although it is not listed in CISA KEV and EPSS is currently low, exploit code is available and the CVSS availability impact is high, so exposed file-processing services should be prioritized for patching.

How an attack unfolds

An attacker creates a PDF containing a FlateDecode-compressed stream with a misleading or attacker-controlled Length value that causes Pillow's PDF stream decoder to request an unsafe decompression buffer size. The attacker then submits the file to any application path that processes PDFs with a vulnerable Pillow version, such as an upload endpoint, conversion service, thumbnail generator, document ingestion worker, or automated batch processor. When Pillow parses the PDF and calls PdfParser.PdfStream.decode(), zlib.decompress() attempts to allocate or expand memory based on the crafted stream characteristics. This can rapidly consume available memory, causing the Python process, container, worker, or host service to terminate or become unresponsive. Repeated submissions can create a sustained denial-of-service condition.

How to fix it

Upgrade Pillow to version 12.3.0 or later wherever it is installed. Treat all Pillow versions from 5.1.0 up to but not including 12.3.0 as affected. Rebuild and redeploy containers, serverless packages, virtual environments, application bundles, and worker images that vendor or pin Pillow. If immediate upgrade is not possible, mitigate by blocking or quarantining untrusted PDF processing, disabling PDF ingestion paths that rely on Pillow, enforcing strict upload size and decompressed-size limits, processing files in memory- and CPU-constrained sandboxes, applying worker timeouts, and isolating document conversion workloads from critical services.

How to confirm the fix worked

Confirm that all runtime environments use Pillow 12.3.0 or later by checking package inventories, lockfiles, container images, and live Python environments. Useful checks include `python -m pip show Pillow`, `python -c "import PIL; print(PIL.__version__)"`, dependency lockfile review, and software composition analysis scans. Validate that deployed containers or serverless artifacts have been rebuilt after dependency updates rather than only updating source manifests. Where safe, test with a controlled regression corpus or vendor-provided proof of concept in a non-production environment to confirm the process no longer experiences abnormal memory growth. Also verify that upload limits, sandbox memory limits, worker restart policies, and monitoring alerts are in place for document-processing services.

Typical attack path

1. Identify an application, API, or processing workflow that accepts PDF files or processes externally supplied documents.
2. Craft a small PDF containing a malicious FlateDecode stream with a dangerous Length value and compression characteristics that trigger excessive decompression memory use.
3. Submit the PDF through an upload form, API request, email/document ingestion flow, message queue, or batch import process.
4. Trigger server-side parsing through Pillow's PdfParser.PdfStream.decode() code path.
5. Cause the Python process or worker to exhaust memory and crash, restart, or become unresponsive.
6. Repeat submissions to keep the affected service degraded or unavailable.

How to detect it

To determine whether this was already exploited, review application, web server, API gateway, file-upload, document-processing, container orchestration, and host logs for PDF submissions followed closely by memory exhaustion or worker crashes. Focus on upload endpoints, background job queues, PDF thumbnail or conversion services, and any Python process using Pillow. Look for repeated small PDF uploads from the same source, sudden increases in failed document-processing jobs, Python traceback entries involving PIL/PdfParser.py or PdfStream.decode, Linux OOM killer messages, Kubernetes `OOMKilled` container statuses, supervisor/systemd restart loops, and application errors involving `zlib.decompress`. Correlate suspicious file submissions with process memory spikes, pod restarts, 5xx responses, queue retries, or service unavailability. Preserve suspicious PDF samples for offline analysis and detonate only in an isolated environment with memory limits.

• PIL/PdfParser.py
• PdfStream.decode
• zlib.decompress
• FlateDecode
• MemoryError
• Cannot allocate memory
• Killed process
• Out of memory: Killed process
• oom-killer
• OOMKilled
• exit code 137
• ContainerStatusUnknown
• Back-off restarting failed container
• CrashLoopBackOff
• worker exited unexpectedly
• PDF stream Length
• /Pillow
• PIL.__version__
• application/pdf

What your security team should do

• Prioritize upgrading Pillow to 12.3.0 or later in internet-facing upload, document-processing, PDF-preview, image-conversion, and asynchronous worker services.
• Search application dependency inventories, SBOMs, container images, and Python virtual environments for Pillow versions >=5.1.0 and <12.3.0.
• Temporarily restrict untrusted PDF uploads or route them to sandboxed processing until patched versions are deployed.
• Apply memory limits, execution timeouts, queue rate limits, and worker isolation to reduce denial-of-service blast radius.
• Review logs for recent crashes, out-of-memory kills, repeated PDF upload attempts, and abnormal worker restarts since the vulnerability was published.
• Add detections for PDF uploads followed by rapid memory exhaustion, process termination, container OOMKilled events, or worker restart loops.
• Ensure dependency pinning and CI/CD checks prevent reintroduction of vulnerable Pillow versions.