Bug 2555864 (CVE-2026-112400)

Summary: CVE-2026-112400 pillow: pillow: Denial of Service via memory exhaustion from crafted GIF image
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: alinfoot, anpicker, anthomas, aprice, bbrownin, cmyers, dfreiber, dnakabaa, doconnor, drow, dschmidt, dtrifiro, ebourniv, ehelms, ggainey, hasun, ilpinto, jburrell, jfula, jlanda, jmitchel, jowilson, jpasqual, jsamir, juwatts, jwong, kaycoth, kshier, lcouzens, ltomasbo, mdellweg, mhayden, mhulan, mwoodson, nmoumoul, nyancey, oezr, omaciel, ometelka, osousa, pcreech, ptisnovs, rbobbitt, rchan, rhel-process-autobot, sbunciak, sdoran, simaishi, smallamp, stcannon, syedriko, tmalecek, vkumar, watson-tool-maintainers, weaton, xdharmai, yguenane, ykashtan
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Pillow. When parsing a crafted GIF image, the library fails to discard rejected frame dimensions after encountering an excessively large image exception. If an application catches this exception and continues processing the image, subsequent operations attempt to allocate memory based on the oversized dimensions. A remote attacker can exploit this issue to exhaust system memory, resulting in a Denial of Service (DoS).
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-19 21:22:05 UTC
Pillow is a Python imaging library. From 9.2.0 until 13.0.0, Pillow can retain a rejected GIF frame size after a decompression-bomb exception. In GifImageFile._seek, a crafted GIF can leave rejected dimensions stored after Image.DecompressionBombError; if an application catches that exception and continues processing the same image object, later seek or load operations allocate according to those dimensions and can exhaust memory, denying service. This issue is fixed in version 13.0.0.