CVE-2026-54060

What it actually does

Pillow versions prior to 12.3.0 can allocate an excessively large bitmap when PIL/FontFile.py assembles glyph images in FontFile.compile(). The vulnerable code creates a combined 1-bit image with Image.new("1", (xsize, ysize)) without first applying Pillow’s decompression bomb size check. A specially crafted font with extreme glyph dimensions or counts can therefore cause very large memory allocation during font conversion, compilation, rendering, or saving workflows. The practical result is denial of service through process memory exhaustion, worker crashes, container restarts, or host-level resource pressure. The flaw does not directly provide code execution, data theft, or privilege escalation based on the available description.

Why it matters to the business

Applications, APIs, background workers, document pipelines, image/font processing services, and SaaS features that accept or process untrusted fonts may be crashed remotely by a crafted input. This can interrupt file upload workflows, rendering services, document generation, preview generation, batch processing, or any dependent service using vulnerable Pillow versions. Although this CVE is not currently in CISA KEV and has a low EPSS score, exploit availability and a network-reachable, unauthenticated CVSS profile make it important for internet-facing or automated processing systems. Organizations with broad Python dependency footprints should treat this as a dependency hygiene and availability risk, especially where Pillow is embedded transitively in web, document, ML, reporting, or media-processing stacks.

How an attack unfolds

An attacker identifies an application endpoint, queue, import pipeline, or document-processing workflow that accepts files later handled by Pillow. The attacker supplies a malicious font file constructed so that Pillow’s FontFile.compile() calculates very large xsize and ysize values when combining glyph bitmaps. In vulnerable versions, Pillow allocates the combined bitmap without invoking its decompression bomb protection. If the requested allocation is large enough, the Python process consumes excessive memory, raises allocation failures, is killed by the operating system or container runtime, or causes the service supervisor to restart it. Repeated submissions can sustain a denial-of-service condition against exposed workers or processing nodes. There is no confirmed KEV or ransomware association in the provided data, but public exploit availability increases the likelihood of opportunistic testing against exposed services.

How to fix it

Upgrade Pillow to version 12.3.0 or later everywhere it is installed, including direct and transitive Python dependencies in application images, build artifacts, virtual environments, notebooks, serverless packages, and worker containers. If immediate upgrade is not possible, reduce exposure by blocking untrusted font uploads, disabling workflows that convert or compile uploaded fonts, validating font dimensions and glyph counts before processing, enforcing strict file size limits, running font/image processing in isolated sandboxes, and applying memory, CPU, timeout, and job-queue limits. Pin the dependency explicitly to a fixed version in requirements files, lockfiles, base images, and build pipelines, then rebuild and redeploy affected services. Because the provided fixed_versions field is empty but the advisory states the fix is in 12.3.0, use Pillow >= 12.3.0 as the remediation target.

How to confirm the fix worked

Confirm all runtime environments report Pillow 12.3.0 or later using package inventory, pip freeze, pip show Pillow, Poetry/Pipenv lockfiles, SBOMs, container scans, and artifact scans. Validate that no deployed image or virtual environment still contains vulnerable PIL/FontFile.py from a pre-12.3.0 Pillow package. Exercise representative upload, conversion, and rendering workflows after upgrade to ensure normal fonts still process correctly. Where feasible, run a controlled regression test with oversized or malformed font inputs in a non-production environment and verify the process rejects, times out, or fails safely without excessive memory growth. Confirm resource controls are active for processing workers, including memory limits, request size limits, queue retry limits, and job timeouts.

Typical attack path

1. Find an application, API, job processor, or conversion service that accepts fonts or documents containing embedded fonts.
2. Confirm or infer that the service uses a vulnerable Pillow release prior to 12.3.0.
3. Create or obtain a crafted font that causes extreme glyph bitmap dimensions or aggregate glyph layout size during FontFile.compile().
4. Submit the crafted font through an upload endpoint, conversion request, rendering job, message queue, or batch import path.
5. Trigger Pillow to compile, convert, render, or save the font so the vulnerable Image.new("1", (xsize, ysize)) allocation path is reached.
6. Cause memory exhaustion, worker termination, container restart, request timeouts, or degradation of adjacent workloads.
7. Repeat the request or distribute submissions across workers to maintain service disruption.

How to detect it

To determine whether exploitation may already have occurred, review application, worker, web server, container, orchestrator, and host logs around file upload, font conversion, document rendering, preview generation, and batch ingestion workflows. Look for sudden memory exhaustion, Python allocation failures, killed worker processes, container OOMKilled events, repeated restarts, request timeouts, and failed jobs involving font files or documents with embedded fonts. Correlate these events with inbound requests that uploaded or submitted .pil, .bdf, .pcf, .ttf, .otf, or document files shortly before the crash. In Python application logs, search for stack traces involving PIL/FontFile.py, FontFile.compile, or Image.new immediately before MemoryError or worker termination. In Linux and Kubernetes environments, review kernel logs, systemd journals, kube events, pod status history, and runtime logs for OOM kills affecting services that import PIL or Pillow. Because the vulnerability is a denial-of-service condition, absence of persistent files or post-exploitation artifacts is expected; detection should focus on crash telemetry, resource exhaustion, repeated malformed inputs, and source IPs or accounts associated with triggering jobs.

• PIL/FontFile.py
• FontFile.compile
• FontFile.py", in compile
• Image.new("1", (xsize, ysize))
• MemoryError
• Out of memory: Killed process
• oom-kill
• OOMKilled
• Killed process
• Cannot allocate memory
• Worker exited unexpectedly
• worker timeout
• PIL.FontFile

What your security team should do

• Inventory all applications, containers, serverless functions, notebooks, build systems, and background workers that include Pillow, prioritizing internet-facing upload and document/image/font processing services.
• Upgrade or rebuild affected assets to Pillow 12.3.0 or later and verify the deployed runtime version, not only the source repository version.
• Prioritize remediation for unauthenticated upload paths, automated batch ingestion, document conversion, preview generation, report generation, and any service that processes files from external users or partners.
• Apply compensating controls while patching: file size limits, font type allowlists, embedded-font restrictions, memory limits, worker isolation, queue throttling, and maximum processing timeouts.
• Search recent logs for unexplained OOM kills, Python MemoryError events, worker restarts, request spikes involving font uploads, and stack traces referencing PIL/FontFile.py or FontFile.compile.
• Add monitoring for repeated failed font-processing jobs from the same source, abnormal memory spikes in Pillow-based workers, and elevated container restarts after file-upload requests.
• Update dependency governance rules to flag Pillow versions earlier than 12.3.0 in CI/CD, SBOM scanning, and container image admission controls.