CVE-2026-55379

What it actually does

Pillow versions prior to 12.3.0 contain a denial-of-service vulnerability in BDF font parsing. The vulnerable code in PIL/BdfFontFile.py reads attacker-controlled BBX width and height values from a BDF font file and passes those dimensions to Image.new() without invoking Pillow's decompression-bomb protection. A malicious BDF file can therefore request creation of an extremely large image object, causing excessive memory allocation and potentially exhausting process or host resources. The impact is availability loss; the vulnerability is not described as enabling code execution or data disclosure.

Why it matters to the business

Applications, APIs, workers, or batch pipelines that process untrusted font or image-related uploads with vulnerable Pillow versions can be crashed or degraded by a crafted BDF font file. This can interrupt document/image processing workflows, consume compute resources, trigger autoscaling or job backlogs, and cause user-facing service outages. Although it is not in CISA KEV and has low EPSS at this time, public exploit availability and network-reachable, unauthenticated scoring mean internet-facing upload or conversion services should treat remediation as urgent where BDF files or archives containing fonts are accepted.

How an attack unfolds

An attacker identifies an application path that uses Pillow to parse BDF font files, either directly through font upload/preview functionality or indirectly through a conversion, rendering, archive-processing, or document-processing workflow. The attacker crafts a BDF file whose BBX declaration contains extremely large width and height values. When the vulnerable Pillow code parses the file, it trusts those dimensions and calls Image.new() without the usual decompression-bomb size check. The process attempts to allocate memory proportional to the declared dimensions, which can cause high memory consumption, process termination by the operating system or container runtime, worker crashes, queue stalls, or broader service instability. Repeated submissions can sustain the denial of service.

How to fix it

Upgrade Pillow to version 12.3.0 or later everywhere it is used. Rebuild and redeploy applications, containers, serverless packages, virtual environments, and worker images that vendor or pin Pillow versions prior to 12.3.0. If immediate upgrade is not possible, reduce exposure by rejecting or quarantining BDF font files from untrusted sources, blocking uploads with BDF signatures, restricting archive contents, enforcing strict file size and dimension limits before parsing, running file-processing workloads with memory and CPU limits, and isolating parsing workers from critical service components. Dependency constraints should be updated to require Pillow >= 12.3.0, and transitive dependency locks should be regenerated.

How to confirm the fix worked

Confirm that runtime environments resolve Pillow to version 12.3.0 or later using package inventories, dependency lockfiles, container SBOMs, and runtime checks such as `python -c "import PIL; print(PIL.__version__)"`. Validate that deployed artifacts, not just source repositories, contain the fixed version. Review upload and processing paths to determine whether BDF fonts can reach Pillow. Where safe and authorized, use a non-production test with oversized BDF BBX dimensions to confirm the application rejects the file or handles it without excessive memory growth. Verify compensating controls by testing MIME/type validation, archive scanning, file allowlists, worker memory limits, and alerting on abnormal memory allocation or repeated worker restarts.

Typical attack path

1. Find a web service, API, background worker, or processing pipeline that accepts uploaded fonts, images, documents, archives, or other files later parsed with Pillow.
2. Create or obtain a malicious BDF font file containing a BBX line with very large width and height values.
3. Submit the crafted file to the vulnerable processing path, often requiring no authentication if the upload or conversion endpoint is public.
4. Trigger Pillow's BDF font parser to read the attacker-controlled dimensions and call Image.new() without decompression-bomb validation.
5. Cause excessive memory allocation, leading to process crashes, container restarts, failed jobs, degraded throughput, or service outage.
6. Repeat submissions or distribute the file across multiple processing jobs to prolong or amplify availability impact.

How to detect it

Look for evidence that untrusted BDF font files were uploaded or processed before crashes, memory spikes, or worker restarts. Relevant sources include web access logs, API gateway logs, application upload logs, file-processing worker logs, container orchestration events, Linux kernel logs, EDR telemetry, object-storage access logs, and job queue failure records. Hunt for `.bdf` file uploads, BDF file headers, BBX declarations with unusually large dimensions, Pillow stack traces referencing `PIL/BdfFontFile.py` or `bdf_char`, Python `MemoryError` exceptions, Linux OOM killer messages, Kubernetes `OOMKilled` container terminations, and repeated restarts of image/font/document processing workers shortly after user-submitted files. Because exploitation primarily causes resource exhaustion, absence of a durable payload does not prove absence of exploitation; correlate suspicious BDF processing with memory exhaustion and service instability.

• .bdf
• STARTFONT
• FONTBOUNDINGBOX
• STARTCHAR
• BBX
• PIL/BdfFontFile.py
• bdf_char
• Image.new
• MemoryError
• Cannot allocate memory
• Killed process
• Out of memory
• oom-kill
• OOMKilled
• CrashLoopBackOff
• PIL.BdfFontFile
• python.*PIL.*BdfFontFile
• BBX 999999
• BBX 1000000
• BBX 2147483647

What your security team should do

• Prioritize upgrading Pillow to 12.3.0 or later in internet-facing upload, rendering, conversion, document-processing, and batch-worker systems.
• Search dependency manifests, lockfiles, SBOMs, container images, and runtime environments for Pillow versions earlier than 12.3.0.
• Identify all application paths that accept BDF fonts or process archives/documents that may contain BDF files, and restrict or block those inputs if not business-critical.
• Apply resource isolation for file-parsing workloads, including container memory limits, worker timeouts, queue rate limits, and crash-loop alerts.
• Add detection for suspicious BDF files containing extreme BBX dimensions and for repeated memory-exhaustion events in Pillow-based workers.
• Review historical logs for uploads or processing failures involving BDF files, out-of-memory kills, and worker restarts since publication.
• Regenerate dependency lockfiles and redeploy all packaged artifacts after upgrading; do not rely solely on repository-level version changes.
• If upgrade is delayed, implement temporary WAF/API gateway/file-validation controls to reject `.bdf` files and BDF file headers from untrusted users.