GHSA-jgpv-4h4c-xhw3

What it actually does

This vulnerability is an uncontrolled resource consumption flaw in Pillow, the Python Imaging Library. When an affected Pillow version processes a specially crafted image, image parsing or decoding can consume excessive CPU, memory, or worker time. The primary technical consequence is denial of service: application workers, background processors, or image-processing pipelines can hang, slow significantly, crash from out-of-memory conditions, or be killed by container/runtime limits. The issue affects Pillow versions prior to 8.1.2.

Why it matters to the business

Applications that accept, transform, resize, thumbnail, scan, or otherwise process untrusted images can be disrupted by a malicious or malformed file. The likely business impact is service degradation or outage in features such as uploads, media processing, document ingestion, user profile images, product images, and asynchronous job queues. Because this advisory has been public for a long time, affected deployments should be treated as avoidable technical debt even though it is not listed in CISA KEV and no mature public exploitation signal was provided.

How an attack unfolds

An attacker identifies an application feature that causes server-side image processing using Pillow, such as an upload endpoint, avatar handler, document conversion workflow, email attachment processor, or service that fetches images from user-supplied URLs. The attacker submits a crafted image designed to trigger excessive resource usage in vulnerable Pillow parsing or decoding logic. When the application opens, validates, resizes, converts, or extracts metadata from the image, the affected Pillow version consumes disproportionate CPU, memory, or processing time. A single request may stall or crash a worker; repeated submissions can exhaust a worker pool, fill job queues, trigger autoscaling, or cause broader service unavailability. The attacker generally does not need code execution; the objective is to make the target spend resources processing attacker-controlled input.

How to fix it

Upgrade Pillow to version 8.1.2 or later; where possible, upgrade to the latest supported Pillow release rather than only the minimum fixed version. Ensure all direct and transitive Python dependencies resolve to a fixed Pillow version, including dependencies embedded in containers, serverless packages, background workers, CI-built artifacts, and offline processing tools. Rebuild and redeploy application images after updating lockfiles such as requirements.txt, Pipfile.lock, poetry.lock, or constraints files. As defense in depth, enforce maximum upload size, pixel-count limits, decoding timeouts, worker memory limits, request rate limits, and queue throttling. Avoid processing untrusted images in privileged long-running application processes; isolate image conversion in constrained workers or sandboxes where practical.

How to confirm the fix worked

Confirm dependency inventories show Pillow version 8.1.2 or later in every runtime that processes images. Validate using package tooling such as `pip show Pillow`, `python -c "import PIL; print(PIL.__version__)"`, dependency lockfile inspection, container image scanning, and software composition analysis. Confirm rebuilt artifacts no longer contain older Pillow wheels or vendored copies. Exercise representative image upload and conversion workflows after the upgrade to verify normal functionality. Validate operational controls by testing that oversized or malformed images are rejected or terminated within configured CPU, memory, request-size, and processing-time limits.

Typical attack path

1. Find an exposed feature that accepts or retrieves image files and processes them server-side.
2. Craft or obtain a malformed image that triggers excessive resource consumption in vulnerable Pillow versions.
3. Submit the image through an upload form, API endpoint, attachment workflow, or URL-ingestion feature.
4. Cause Pillow to parse, decode, resize, convert, or inspect the image.
5. Force high CPU, memory exhaustion, worker hangs, process termination, or queue backlog.
6. Repeat submissions to amplify the denial-of-service effect across application workers or processing infrastructure.

How to detect it

Look for signs of attempted denial of service against image-processing paths rather than compromise artifacts. Useful log sources include web access logs, API gateway logs, WAF logs, application logs around upload/conversion/thumbnail operations, background job queue telemetry, container runtime events, process supervisor logs, and host metrics. Investigate repeated uploads or fetches of unusual image files followed by high CPU, memory growth, worker timeouts, 5xx responses, OOM kills, or sudden queue backlog. Correlate request timestamps, source IPs, user accounts, filenames, content types, and job IDs with application worker crashes or restarts. Because this flaw is a resource-exhaustion condition, successful exploitation may leave no persistent file, process, registry key, or network indicator beyond the triggering image and associated availability telemetry.

What your security team should do

• Prioritize upgrading Pillow to 8.1.2 or later in all services that process user-controlled or externally sourced images.
• Search repositories, lockfiles, container images, and deployed packages for vulnerable Pillow versions below 8.1.2.
• Identify externally reachable image upload, thumbnailing, conversion, metadata extraction, and URL-fetching workflows that use Pillow.
• Apply compensating controls for image-processing endpoints: file-size limits, pixel limits, timeouts, memory limits, rate limits, and queue backpressure.
• Review recent availability incidents, worker crashes, OOM kills, and image-processing queue spikes for possible abuse.
• Add dependency scanning gates to prevent reintroduction of Pillow versions older than 8.1.2.
• Prefer isolated image-processing workers with restricted privileges and resource quotas for untrusted media.