CVE-2026-55380

What it actually does

Pillow versions prior to 12.3.0 parse GD 2.x image headers in PIL/GdImageFile.py without applying the normal decompression-bomb size check. A crafted .gd file can declare extremely large image dimensions, causing Pillow to store those dimensions and later attempt excessive C-heap memory allocation when the image is loaded or processed. The practical impact is unauthenticated denial of service against applications, APIs, workers, or pipelines that accept and process untrusted GD images using vulnerable Pillow versions. The flaw does not directly provide code execution, data theft, or data modification, but it can crash the Python process, exhaust container or host memory, kill worker pools, or destabilize dependent services.

Why it matters to the business

Organizations that allow image uploads, attachment processing, document conversion, media ingestion, thumbnail generation, or automated image analysis may experience service outages or degraded performance if an attacker submits a malicious GD image. Because exploitation requires only a crafted file and the vulnerability has publicly available exploit information, internet-facing upload paths and automated processing queues should be prioritized even though this CVE is not currently listed in CISA KEV and has a low EPSS score. Disruption may include application downtime, failed background jobs, autoscaling spikes, increased infrastructure cost, queue backlogs, and loss of availability for customer-facing workflows that depend on image processing.

How an attack unfolds

An attacker identifies an application or service that uses Pillow to process user-supplied images, such as an upload endpoint, messaging attachment processor, batch import job, or media transformation service. The attacker crafts a GD 2.x image file with header dimensions large enough to force excessive memory allocation but structured enough for Pillow to recognize it as a GD image. The file is submitted through an exposed upload, API, email attachment, archive, or other ingestion path. When the vulnerable Pillow GD parser opens the file, it records the untrusted dimensions without invoking the decompression-bomb protection that normally rejects oversized images. Subsequent loading or processing causes the Python process or its native heap allocations to consume very large amounts of memory. The affected worker may raise memory allocation errors, be terminated by the operating system or container runtime, or cause host-level memory pressure. Repeated submissions can sustain denial of service, exhaust worker pools, and prevent legitimate image-processing tasks from completing.

How to fix it

Upgrade Pillow to version 12.3.0 or later wherever it is installed, including application dependencies, worker images, build artifacts, notebooks, serverless packages, containers, and transitive dependency bundles. Rebuild and redeploy applications after upgrading; do not rely only on updating a base image if the application vendors its own Python packages. If immediate upgrade is not possible, mitigate by rejecting or quarantining GD/GD2 image files from untrusted sources, enforcing strict file-type allowlists, validating image dimensions before processing, imposing request and file-size limits, running image parsing in memory- and CPU-limited sandboxes, and isolating image-processing workers from critical application processes. Configure container memory limits, worker timeouts, queue rate limits, and retry caps so a single malformed image cannot repeatedly consume resources. Where supported, use dependency pinning or constraints to require Pillow >= 12.3.0 across all services.

How to confirm the fix worked

Confirm the deployed runtime uses Pillow 12.3.0 or later by checking package inventories, SBOMs, container image scans, and runtime package metadata such as `python -m pip show Pillow` or `python -c "import PIL; print(PIL.__version__)"`. Verify that no application images, virtual environments, Lambda/serverless layers, build caches, or offline worker environments still contain Pillow versions earlier than 12.3.0. Test upload and ingestion controls to ensure GD/GD2 files are either safely rejected or processed only by patched workers. Review dependency lock files, such as requirements.txt, constraints.txt, Pipfile.lock, poetry.lock, and conda environment files, for vulnerable Pillow pins. After deployment, run a controlled negative test with an oversized or malformed GD file in a non-production environment and confirm the process rejects it or handles it without abnormal memory growth, worker crashes, or queue instability.

Typical attack path

1. Locate an application, API, worker, or processing pipeline that accepts image files and uses Pillow before version 12.3.0.
2. Create or obtain a malicious GD 2.x file with oversized dimensions in the image header.
3. Submit the crafted .gd file through an upload form, API request, attachment mechanism, archive import, or queued processing workflow.
4. Trigger Pillow to open or load the file using the vulnerable GD image parser.
5. Cause excessive C-heap memory allocation during image loading or processing.
6. Crash or kill the affected Python process, exhaust container or host memory, or tie up image-processing workers.
7. Repeat submissions to sustain service degradation or denial of service.

How to detect it

To determine whether exploitation has already occurred, review application, API gateway, web server, object storage, message queue, worker, container runtime, and host operating system logs for image uploads or processing jobs involving GD/GD2 files followed by memory exhaustion, worker crashes, process restarts, HTTP 500/502/503 responses, queue retries, or OOM-kill events. Focus on time windows where image-processing memory usage spiked, containers restarted unexpectedly, or background job queues accumulated failures. Look for repeated submissions from the same source IP, account, API token, user agent, or automation pattern that coincide with failed image decoding or abnormal memory growth. Examine uploaded artifacts, quarantine buckets, temporary directories, and failed-job payloads for files with .gd or .gd2 extensions or GD/GD2 signatures, especially unusually small files that declare extremely large dimensions. In Python logs, search for Pillow GD parser references, MemoryError exceptions, allocation failures, abrupt process termination, and worker supervision messages. In Kubernetes or containerized environments, correlate pod restarts, OOMKilled status, exit code 137, and container memory-limit events with image-processing requests. Absence of GD-specific parser errors does not rule out exploitation because the vulnerable path bypasses the decompression-bomb check that would normally emit oversized-image warnings.

• .gd
• .gd2
• GdImageFile
• PIL/GdImageFile.py
• PIL.GdImageFile
• MemoryError
• Unable to allocate
• cannot allocate memory
• Out of memory
• Killed process
• OOMKilled
• exit code 137
• signal 9
• worker exited unexpectedly
• worker timeout
• image processing failed
• gd2
• GD2

What your security team should do

• Inventory all services, containers, serverless functions, notebooks, CI jobs, and background workers that include Pillow and prioritize any that process user-supplied images.
• Upgrade Pillow to 12.3.0 or later and rebuild all affected deployment artifacts.
• Prioritize internet-facing upload endpoints, attachment processors, media conversion services, and asynchronous image-processing queues because exploitation can be unauthenticated and exploit code is available.
• Temporarily block or quarantine GD/GD2 files from untrusted sources if patching cannot be completed quickly.
• Add resource controls around image processing, including container memory limits, process isolation, worker timeouts, file-size limits, dimension limits, queue throttling, and retry limits.
• Search recent application, worker, container, and host logs for unexplained memory exhaustion, OOM kills, crashes, or repeated processing failures associated with GD image inputs.
• Update SCA, SBOM, and CI/CD dependency policies to fail builds that include Pillow versions earlier than 12.3.0.
• Confirm monitoring alerts exist for spikes in image-processing memory usage, worker restarts, failed jobs, HTTP 5xx responses on upload paths, and queue backlog growth.