CVE-2026-42310

What it actually does

Pillow versions 4.2.0 through before 12.2.0 can enter an indefinite hang when processing a maliciously crafted PDF, causing the affected process to consume 100% CPU. The flaw impacts availability only: it does not indicate confidentiality loss, integrity modification, privilege escalation, or remote code execution. In services that process untrusted PDFs, the vulnerability can lock worker threads or processes and degrade or exhaust application capacity.

Why it matters to the business

Applications that use Pillow to process uploaded or imported PDFs can become unresponsive when they encounter a malicious PDF, potentially causing degraded service, stuck worker processes, job queue backlogs, failed document/image workflows, and increased infrastructure costs from CPU exhaustion. The CVSS score is moderate and EPSS is low, with no known KEV listing or ransomware association, but the issue is operationally relevant for internet-facing upload, document conversion, thumbnailing, and automated processing services because a single crafted file may tie up a worker indefinitely.

How an attack unfolds

An attacker identifies an application path that accepts or processes PDF files using Pillow versions 4.2.0 through before 12.2.0. They submit a specially crafted PDF through an upload form, API, email/document ingestion path, batch import process, or other file-processing workflow. When the vulnerable Pillow code attempts to parse or handle the PDF, the processing loop can hang indefinitely and consume a full CPU core. If the service lacks strict per-task timeouts, worker isolation, resource limits, or queue controls, repeated submissions can exhaust available workers or CPU capacity, making the application slow or unavailable to legitimate users. This is a denial-of-service condition rather than code execution or data compromise based on the available description.

How to fix it

Upgrade Pillow to version 12.2.0 or later wherever PDF processing may occur. If direct fixed package metadata is unavailable, inventory Python environments, containers, serverless packages, application dependencies, and transitive dependencies for Pillow versions from 4.2.0 up to but not including 12.2.0, then rebuild and redeploy affected artifacts. Where immediate upgrade is not possible, reduce exposure by disabling untrusted PDF processing through Pillow, validating and rejecting unexpected PDF uploads, routing PDF handling to a hardened/sandboxed converter, enforcing strict per-request and per-job CPU/time limits, limiting upload size and page count, using worker process recycling, and applying container or OS-level CPU quotas. Ensure asynchronous workers have maximum execution times and that failed or timed-out jobs do not retry indefinitely.

How to confirm the fix worked

Confirm remediation by checking runtime dependency versions in deployed environments, not only source manifests. Use package manager output such as `python -m pip show Pillow`, `python -m pip freeze`, Software Bill of Materials data, container image scans, and lockfile review to verify Pillow is 12.2.0 or later. Validate that all rebuilt containers and serverless/application packages contain the upgraded library. Exercise PDF upload and processing workflows in staging with malformed or oversized PDFs to confirm processing is bounded by timeouts and does not create sustained CPU saturation. Also confirm that task queues enforce execution limits, retries are capped, and worker processes are recycled or terminated when they exceed safe runtime thresholds.

Typical attack path

1. Find an application endpoint or workflow that accepts, imports, converts, thumbnails, or otherwise processes PDF files.
2. Confirm or infer that the backend uses a vulnerable Pillow version for PDF/image handling.
3. Create or obtain a malicious PDF that triggers the Pillow hang condition.
4. Submit the PDF through the upload/API/import path or place it where an automated processor will ingest it.
5. Wait for the vulnerable Python worker to parse the PDF and enter an indefinite high-CPU loop.
6. Repeat submissions or trigger retries to consume additional workers or CPU capacity.
7. Cause degraded performance, queue buildup, request failures, or service unavailability until processes are killed, restarted, or protected by resource controls.

How to detect it

Review application, worker, container, and host telemetry for PDF-processing requests followed by sustained 100% CPU usage, hung Python processes, request timeouts, job retries, or queue buildup. Useful sources include web access logs, application logs, task queue logs, container orchestration events, process monitoring, APM traces, EDR telemetry, and CPU utilization metrics. Look for repeated or suspicious PDF uploads/imports immediately preceding service degradation, especially where Python processes running Pillow remain active without completing work. Because no public exploit maturity or fixed exploit signature is indicated, detection should focus on behavioral indicators: long-running image/PDF parsing tasks, high CPU without corresponding I/O, repeated failures/timeouts in document conversion endpoints, and files that consistently reproduce a hang when processed in a controlled sandbox.

• python process consuming sustained ~100% CPU while processing a PDF
• PIL.PdfImagePlugin
• Pillow
• Image.open
• request timeout during PDF processing
• worker timeout while processing PDF
• task exceeded time limit while processing PDF
• document conversion timeout
• thumbnail generation timeout
• PDF processing job retry
• CPU throttling on Python worker
• SIGKILL after worker timeout
• killed worker due to timeout
• application/pdf upload followed by Python CPU spike

What your security team should do

• Prioritize patching internet-facing or user-controlled file upload, document conversion, thumbnail generation, and batch ingestion services that use Pillow before 12.2.0.
• Inventory application repositories, lockfiles, container images, virtual environments, and build artifacts for vulnerable Pillow versions and require upgrade to 12.2.0 or later.
• Add or verify hard timeouts, CPU limits, memory limits, and worker recycling for all untrusted file-processing workloads.
• Restrict PDF processing paths if they are not business-critical, and validate file type, size, and complexity before processing.
• Monitor for repeated PDF uploads followed by Python worker CPU saturation, timeouts, job backlog growth, or service unavailability.
• Add regression tests using representative malformed PDFs in a controlled environment to ensure processing fails safely rather than hanging.
• Review task queue retry policies to prevent a malicious file from being retried indefinitely and repeatedly consuming workers.