CVE-2026-112400
Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
8.7
Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS
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.
- Record
CVE-2026-112400- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-400, CWE-770
- Updated
- 2026-11-02
EUVDEUVD-2026-104636
8.7
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.
- Record
EUVD-2026-104636- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-65qm-jvmh-6pqg
8.7
Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS
============================================================================
GIF seek keeps rejected size after DecompressionBombError, allowing DoS
Location: src/PIL/GifImagePlugin.py:293 in GifImageFile._seek()
Commit: a707c6b21c313880d0771e54965d142dd42358b6
============================================================================
A GIF of about 60 bytes can make Pillow allocate gigabytes of memory. This affects applications that catch the "image too large" error raised while stepping to a later animation frame and then keep using the same image object. Pillow correctly refuses the oversized frame, but it stores the refused dimensions on the image object anyway, and later operations size their memory from them. An attacker who can upload a GIF to such a service can exhaust its memory: the process either fails with an out-of-memory error after committing gigabytes, or is killed by the operating system. There is no memory corruption.
The bug is in GifImageFile._seek() (src/PIL/GifImagePlugin.py:292-294). When a frame's extent enlarges the image, the code assigns the new size to self._size and only then calls Image._decompression_bomb_check(). Nothing restores the old size when DecompressionBombError is raised, because seek() only rolls back on EOFError. After the caught error, im.size reports the rejected size while the pixel buffer im.im is still the 1×1 first frame. Because the extent is a 16-bit offset plus a 16-bit size, that rejected size can be as large as 131070×131070.
In the attached reproducer, the rejected size is 40000×40000. A retried seek(1) followed by load() then reaches load_prepare(), which calls Image.core.fill() with that size to decode a single pixel. Peak memory rises from 17 MiB to 1700 MiB before a 3 GiB address-space cap stops the next allocation. Image.new("RGB", im.size, ...) and rotate(..., expand=True) also allocate from the stale size.
The default paths are unaffected: plain Image.open() plus load(), ImageSequence.Iterator, and n_frames/is_animated. The ordering was introduced in c9f1b35e9810 ("Added GIF decompression bomb check", 2022-06-30, first released in 9.2.0), the check added for CVE-2022-45198. The two dispose-extent checks later in the same function already validate before using the size, and the attached patch makes this check follow the same order.
Details
GifImageFile._seek() lets a later frame enlarge the image, and performs the
decompression-bomb check for the new size only after storing it on the object:
# src/PIL/GifImagePlugin.py:289-294 (GifImageFile._seek)
x0, y0 = i16(s, 0), i16(s, 2)
x1, y1 = x0 + i16(s, 4), y0 + i16(s, 6)
if (x1 > self.size[0] or y1 > self.size[1]) and update_image:
self._size = max(x1, self.size[0]), max(y1, self.size[1]) # state mutated
Image._decompression_bomb_check(self._size) # ...then validated
_decompression_bomb_check() (src/PIL/Image.py:3586) raises
DecompressionBombError for anything above 2 * MAX_IMAGE_PIXELS
(178 956 970 px by default), but by then self._size already holds the rejected
value and nothing restores it: seek() (GifImagePlugin.py:166-179) only rolls
back on EOFError, and _seek(0) only ever grows _size. The object that the
application still holds therefore reports im.size == (40000, 40000) while
im.im is the 1×1 buffer of frame 0. Compare the two dispose-extent checks a
few lines further down in the same function (GifImagePlugin.py:383 and :407),
which call _decompression_bomb_check(dispose_size) before the corresponding
Image.core.fill(), and TiffImagePlugin.load_prepare()
(src/PIL/TiffImagePlugin.py:1319-1321), which checks _tile_size before
allocating from it.
With this 60-byte GIF (hex)
47494638396101000100800000000000ffffff GIF89a, 1x1 screen, 2-entry global palette
2c000000000100010000 02 024401 00 frame 0: 1x1 @ (0,0), LZW data…
- Record
GHSA-65qm-jvmh-6pqg- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-400
- Updated
- 2026-11-02
NVD
8.7
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.
- Record
CVE-2026-112400- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Weakness
- CWE-400, CWE-770
- Updated
- 2026-11-02
OSV
8.7
Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS
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.
- Record
CVE-2026-112400- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-400, CWE-770
- Updated
- 2026-11-03
OSVDEBIAN-CVE-2026-112400
7.5
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.
- Record
DEBIAN-CVE-2026-112400- CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Updated
- 2026-11-02
Show 12 moreShow less
OSVGHSA-65qm-jvmh-6pqg
8.7
Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS
============================================================================
GIF seek keeps rejected size after DecompressionBombError, allowing DoS
Location: src/PIL/GifImagePlugin.py:293 in GifImageFile._seek()
Commit: a707c6b21c313880d0771e54965d142dd42358b6
============================================================================
A GIF of about 60 bytes can make Pillow allocate gigabytes of memory. This affects applications that catch the "image too large" error raised while stepping to a later animation frame and then keep using the same image object. Pillow correctly refuses the oversized frame, but it stores the refused dimensions on the image object anyway, and later operations size their memory from them. An attacker who can upload a GIF to such a service can exhaust its memory: the process either fails with an out-of-memory error after committing gigabytes, or is killed by the operating system. There is no memory corruption.
The bug is in GifImageFile._seek() (src/PIL/GifImagePlugin.py:292-294). When a frame's extent enlarges the image, the code assigns the new size to self._size and only then calls Image._decompression_bomb_check(). Nothing restores the old size when DecompressionBombError is raised, because seek() only rolls back on EOFError. After the caught error, im.size reports the rejected size while the pixel buffer im.im is still the 1×1 first frame. Because the extent is a 16-bit offset plus a 16-bit size, that rejected size can be as large as 131070×131070.
In the attached reproducer, the rejected size is 40000×40000. A retried seek(1) followed by load() then reaches load_prepare(), which calls Image.core.fill() with that size to decode a single pixel. Peak memory rises from 17 MiB to 1700 MiB before a 3 GiB address-space cap stops the next allocation. Image.new("RGB", im.size, ...) and rotate(..., expand=True) also allocate from the stale size.
The default paths are unaffected: plain Image.open() plus load(), ImageSequence.Iterator, and n_frames/is_animated. The ordering was introduced in c9f1b35e9810 ("Added GIF decompression bomb check", 2022-06-30, first released in 9.2.0), the check added for CVE-2022-45198. The two dispose-extent checks later in the same function already validate before using the size, and the attached patch makes this check follow the same order.
Details
GifImageFile._seek() lets a later frame enlarge the image, and performs the
decompression-bomb check for the new size only after storing it on the object:
# src/PIL/GifImagePlugin.py:289-294 (GifImageFile._seek)
x0, y0 = i16(s, 0), i16(s, 2)
x1, y1 = x0 + i16(s, 4), y0 + i16(s, 6)
if (x1 > self.size[0] or y1 > self.size[1]) and update_image:
self._size = max(x1, self.size[0]), max(y1, self.size[1]) # state mutated
Image._decompression_bomb_check(self._size) # ...then validated
_decompression_bomb_check() (src/PIL/Image.py:3586) raises
DecompressionBombError for anything above 2 * MAX_IMAGE_PIXELS
(178 956 970 px by default), but by then self._size already holds the rejected
value and nothing restores it: seek() (GifImagePlugin.py:166-179) only rolls
back on EOFError, and _seek(0) only ever grows _size. The object that the
application still holds therefore reports im.size == (40000, 40000) while
im.im is the 1×1 buffer of frame 0. Compare the two dispose-extent checks a
few lines further down in the same function (GifImagePlugin.py:383 and :407),
which call _decompression_bomb_check(dispose_size) before the corresponding
Image.core.fill(), and TiffImagePlugin.load_prepare()
(src/PIL/TiffImagePlugin.py:1319-1321), which checks _tile_size before
allocating from it.
With this 60-byte GIF (hex)
47494638396101000100800000000000ffffff GIF89a, 1x1 screen, 2-entry global palette
2c000000000100010000 02 024401 00 frame 0: 1x1 @ (0,0), LZW data…
- Record
GHSA-65qm-jvmh-6pqg- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - Weakness
- CWE-400
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-112400
8.7
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.
- Record
UBUNTU-CVE-2026-112400- CVSS 4.0
- 8.7 High
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N - CVSS 3.1
- 7.5 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - Updated
- 2026-11-04
OSVBIT-pillow-2026-112400 No score
Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS
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.
- Record
BIT-pillow-2026-112400- Updated
- 2026-11-02
OSVCLSA-2026-1792576513 No score
TuxCare security update for pillow (11 CVEs)
TuxCare rebuilt pillow to address 11 CVEs. Fixed in 11.3.0.post7+tuxcare.
- Record
CLSA-2026-1792576513- Updated
- 2026-11-02
OSVCLSA-2026-1792580209 No score
TuxCare security update for pillow (11 CVEs)
TuxCare rebuilt pillow to address 11 CVEs. Fixed in 11.2.1.post9+tuxcare.
- Record
CLSA-2026-1792580209- Updated
- 2026-11-02
OSVCLSA-2026-1792580364 No score
TuxCare security update for pillow (11 CVEs)
TuxCare rebuilt pillow to address 11 CVEs. Fixed in 10.4.0.post11+tuxcare.
- Record
CLSA-2026-1792580364- Updated
- 2026-11-02
OSVCLSA-2026-1792631285 No score
TuxCare security update for pillow (11 CVEs)
TuxCare rebuilt pillow to address 11 CVEs. Fixed in 9.5.0.post9+tuxcare.
- Record
CLSA-2026-1792631285- Updated
- 2026-11-02
OSVCLSA-2026-1792648426 No score
TuxCare security update for pillow (10 CVEs)
TuxCare rebuilt pillow to address 10 CVEs. Fixed in 9.4.0.post10+tuxcare.
- Record
CLSA-2026-1792648426- Updated
- 2026-11-02
OSVCLSA-2026-1793614247 No score
TuxCare security update for pillow (1 CVE)
TuxCare rebuilt pillow to address 1 CVE. Fixed in 8.4.0.post13+tuxcare.
- Record
CLSA-2026-1793614247- Updated
- 2026-11-02
OSVopenSUSE-SU-2026:12230-1 No score
python313-Pillow-13.0.0-1.1 on GA media
These are all security issues fixed in the python313-Pillow-13.0.0-1.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2026:12230-1- Updated
- 2026-11-02
OSVROOT-APP-PYPI-CVE-2026-112400 No score
CVE-2026-112400 in pillow - Patched by Root
Root has patched CVE-2026-112400 in the pillow package for Root:PyPI. Multiple fixed versions available.
- Record
ROOT-APP-PYPI-CVE-2026-112400- Updated
- 2026-11-06
OSVSUSE-SU-2026:5038-1 No score
Security update for python-Pillow
This update for python-Pillow fixes the following issues:
- CVE-2026-96636: decompression-bomb protection bypass via multi-frame
seek()in MPO and DCX (bsc#1286802). - CVE-2026-96637: decompression bomb check bypass in
SpiderImagePlugin.seek()leads to unbounded allocation DoS (bsc#1286801). - CVE-2026-96640: PDF append accepts malformed shared page-tree DAG, which can cause resource exhaustion (bsc#1286798).
- CVE-2026-96641: reachable undefined behavior in native integer operations can lead to denial of service or logic integrity compromise (bsc#1286797).
- CVE-2026-96642:
TarIOnegative size field causes infinite CPU-spin loop (bsc#1286796). - CVE-2026-112390: Denial of Service via infinite loop during crafted MIC image parsing (bsc#1286256).
- CVE-2026-112391: Denial of Service via unbounded recursion in PDF parser (bsc#1286273).
- CVE-2026-112392: Denial of Service via zero-size images in rank filters (bsc#1286287).
- CVE-2026-112393: heap buffer overflow and stale-heap disclosure in _tiffWriteProc when saving compressed TIFF data (bsc#1286325).
- CVE-2026-112394:
P;2LandP;4Ldecoders may read 1 to 3 bytes past the passed buffer size (bsc#1286311). - CVE-2026-112397: out-of-bounds access in
_imagingmorphon a zero-width image (bsc#1286314). - CVE-2026-112398: heap buffer overflow in FPX JPEG decoding can lead to code execution (bsc#1286406).
- CVE-2026-112399: Denial of service via crafted APNG image (bsc#1286368).
- CVE-2026-112400: Denial of Service via memory exhaustion from crafted GIF image (bsc#1286370).
- CVE-2026-112401: Denial of Service via crafted GIF comments (bsc#1286372).
- CVE-2026-112402: Denial of service via double free during image transformation (bsc#1286381).
- CVE-2026-112403: heap buffer overflow in
ImagingJpegDecodeallows for code execution (bsc#1286405). - CVE-2026-112405: NULL pointer dereference in
Image.mergevia an unvalidated band 0 (bsc#1286404). - CVE-2026-112406: infinite loop in
PdfParser.rewrite_pageson page treeParentcycle (bsc#1286403). - CVE-2026-112891: quadratic GIF comment copying during save (bsc#1286402).
- CVE-2026-112892: MSP RLE decoder expands a tiny file into unbounded memory (bsc#1286401).
- CVE-2026-112894: Denial of Service via crafted multi-frame image conversion (bsc#1286408).
- CVE-2026-112895: Denial of service via crafted PDF during append operations (bsc#1286411).
- CVE-2026-112896: TIFF encoder
ColorMapplane-size mismatch causes a heap out-of-bounds read (bsc#1286400). - CVE-2026-112897:
TiffDecodereturns uninitialized memory as pixels for short JPEG strips (bsc#1286398). - CVE-2026-112899: EPS
load(scale)lets Ghostscript render past the decompression bomb limit (bsc#1286489). - CVE-2026-112900: argument Injection in Ghostscript call can lead to remote code execution (bsc#1286397).
- CVE-2026-112901: ReDoS in
XbmImagePlugincan be triggered by 512-byte file (bsc#1286396). - CVE-2026-112902: memory disclosure and segfault in libtiff encoder via crafted TIFF tags (bsc#1286804).
- Record
SUSE-SU-2026:5038-1- Updated
- 2026-11-03
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
pillowPyPI |
9.2.0 up to 13.0.0 | 13.0.0 |
pillowBitnami |
9.2.0 up to 13.0.0 | 13.0.0 |
pillowTuxCare:PyPI From an advisory covering 11 CVEs |
11.3.0 up to 11.3.0.post7+tuxcare, plus listed versions 11.3.0.post1+tuxcare11.3.0.post2+tuxcare11.3.0.post3+tuxcare11.3.0.post4+tuxcare11.3.0.post5+tuxcare11.3.0.post6+tuxcare |
11.3.0.post7+tuxcare |
pillowTuxCare:PyPI From an advisory covering 11 CVEs |
11.2.1 up to 11.2.1.post9+tuxcare, plus listed versions 11.2.1.post1+tuxcare11.2.1.post2+tuxcare11.2.1.post3+tuxcare11.2.1.post4+tuxcare11.2.1.post5+tuxcare11.2.1.post6+tuxcare11.2.1.post7+tuxcare11.2.1.post8+tuxcare |
11.2.1.post9+tuxcare |
pillowTuxCare:PyPI From an advisory covering 11 CVEs |
10.4.0 up to 10.4.0.post11+tuxcare, plus listed versions 10.4.0.post1+tuxcare10.4.0.post10+tuxcare10.4.0.post2+tuxcare10.4.0.post3+tuxcare10.4.0.post4+tuxcare Show 5 moreShow less10.4.0.post5+tuxcare10.4.0.post6+tuxcare10.4.0.post7+tuxcare10.4.0.post8+tuxcare10.4.0.post9+tuxcare |
10.4.0.post11+tuxcare |
pillowTuxCare:PyPI From an advisory covering 11 CVEs |
9.5.0 up to 9.5.0.post9+tuxcare, plus listed versions 9.5.0.post1+tuxcare9.5.0.post2+tuxcare9.5.0.post3+tuxcare9.5.0.post4+tuxcare9.5.0.post5+tuxcare9.5.0.post6+tuxcare9.5.0.post7+tuxcare9.5.0.post8+tuxcare |
9.5.0.post9+tuxcare |
pillowTuxCare:PyPI From an advisory covering 10 CVEs |
9.4.0 up to 9.4.0.post10+tuxcare, plus listed versions 9.4.0.post1+tuxcare9.4.0.post2+tuxcare9.4.0.post3+tuxcare9.4.0.post4+tuxcare9.4.0.post5+tuxcare Show 4 moreShow less9.4.0.post6+tuxcare9.4.0.post7+tuxcare9.4.0.post8+tuxcare9.4.0.post9+tuxcare |
9.4.0.post10+tuxcare |
pillowTuxCare:PyPI |
8.4.0 up to 8.4.0.post13+tuxcare, plus listed versions 8.4.0.post1+tuxcare8.4.0.post10+tuxcare8.4.0.post11+tuxcare8.4.0.post12+tuxcare8.4.0.post2+tuxcare Show 7 moreShow less8.4.0.post3+tuxcare8.4.0.post4+tuxcare8.4.0.post5+tuxcare8.4.0.post6+tuxcare8.4.0.post7+tuxcare8.4.0.post8+tuxcare8.4.0.post9+tuxcare |
8.4.0.post13+tuxcare |
pillowDebian:12 |
All versions, plus listed versions 10.0.0-110.1.0-110.2.0-110.3.0-110.3.0-2 Show 19 moreShow less10.4.0-110.4.0-1.111.1.0-111.1.0-211.1.0-311.1.0-411.1.0-511.2.1-111.3.0-112.0.0-112.1.0-112.1.1-112.1.1-212.2.0-112.3.0-113.0.0-19.4.0-1.19.4.0-1.1+deb12u19.5.0-1 |
None known |
pillowDebian:13 |
All versions, plus listed versions 11.1.0-511.1.0-5+deb13u111.1.0-5+deb13u211.1.0-5+deb13u311.1.0-5+deb13u4 Show 9 moreShow less11.2.1-111.3.0-112.0.0-112.1.0-112.1.1-112.1.1-212.2.0-112.3.0-113.0.0-1 |
None known |
Show 9 moreShow less
| Package | Affected | Fixed |
|---|---|---|
pillowDebian:14 |
All versions, plus listed versions 11.1.0-511.2.1-111.3.0-112.0.0-112.1.0-1 Show 5 moreShow less12.1.1-112.1.1-212.2.0-112.3.0-113.0.0-1 |
None known |
pillowPyPI |
9.2.0 up to 13.0.0, plus listed versions 10.0.010.0.110.1.010.2.010.3.0 Show 13 moreShow less10.4.011.0.011.1.011.2.111.3.012.0.012.1.012.1.112.2.012.3.09.3.09.4.09.5.0 |
13.0.0 |
pillowRoot:PyPI |
before 12.3.0+aikido.1 | 12.3.0+aikido.110.3.0+aikido.1610.4.0+aikido.1412.3.0+aikido.210.2.0+aikido.112.2.0+aikido.810.4.0+aikido.1512.1.0+aikido.1511.3.0+aikido.1110.3.0+aikido.1710.4.0+aikido.1610.1.0+aikido.112.3.0+aikido.310.3.0+aikido.1810.2.0+aikido.210.3.0+aikido.1912.3.0+aikido.410.4.0+aikido.1710.3.0+aikido.209.4.0+aikido.111.0.0+aikido.1412.2.0+aikido.99.5.0+aikido.1910.4.0+aikido.18 |
python-PillowSUSE:Linux Enterprise Module for Package Hub 15 SP7 From an advisory covering 29 CVEs |
before 7.2.0-150300.3.33.1 | 7.2.0-150300.3.33.1 |
pillow-python2Ubuntu:Pro:20.04:LTS |
All versions, plus listed versions 6.2.1-3~build16.2.1-36.2.1-3ubuntu0.1~esm16.2.1-3ubuntu0.1~esm2 |
None known |
pillowUbuntu:24.04:LTS |
All versions, plus listed versions 10.0.0-110.1.0-110.2.0-110.2.0-1build110.2.0-1ubuntu110.2.0-1ubuntu1.210.2.0-1ubuntu1.310.2.0-1ubuntu1.4 |
None known |
pillowUbuntu:26.10 |
All versions, plus listed versions 12.1.1-2ubuntu112.3.0-1ubuntu1 |
None known |
pillowUbuntu:26.04:LTS |
All versions, plus listed versions 11.3.0-1ubuntu111.3.0-1ubuntu212.0.0-1ubuntu112.1.1-1ubuntu112.1.1-2ubuntu1 Show 4 moreShow less12.1.1-2ubuntu1.112.1.1-2ubuntu1.212.1.1-2ubuntu1.312.1.1-2ubuntu1.4 |
None known |
python-PillowopenSUSE:Tumbleweed From an advisory covering 14 CVEs |
before 13.0.0-1.1 | 13.0.0-1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected | OSV | |
| affected | ||
| affected | OSV | |
| affected | OSV | |
| affected | OSV | |
| affected | OSV | |
| affected, facts | OSV | |
| affected, aliases, references | OSV | |
| affected | OSV | |
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-112400 is a high vulnerability (CVSS 8.7) in Python Pillow, published October 19, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.59%, the 48th percentile. Fixed in pillow 13.0.0.
References
github.com/python-pillow/Pillow/security/advisories/GHSA-65qm-jvmh-6pqg
github.com/python-pillow/Pillow/commit/6faed707cfb760a4cbd726ddc8406f576cf35bf7
github.com/python-pillow/Pillow/releases/tag/13.0.0
nvd.nist.gov/vuln/detail/CVE-2026-112400
github.com/advisories/GHSA-65qm-jvmh-6pqg
github.com/CVEProject/cvelistV5/tree/main/cves/2026/112xxx/CVE-2026-112400.json
Show 66 moreShow less
security-tracker.debian.org/tracker/CVE-2026-112400
github.com/python-pillow/Pillow
suse.com/support/update/announcement/2026/suse-su-20265038-1
bugzilla.suse.com/1286256
bugzilla.suse.com/1286273
bugzilla.suse.com/1286287
bugzilla.suse.com/1286311
bugzilla.suse.com/1286314
bugzilla.suse.com/1286325
bugzilla.suse.com/1286368
bugzilla.suse.com/1286370
bugzilla.suse.com/1286372
bugzilla.suse.com/1286381
bugzilla.suse.com/1286396
bugzilla.suse.com/1286397
bugzilla.suse.com/1286398
bugzilla.suse.com/1286400
bugzilla.suse.com/1286401
bugzilla.suse.com/1286402
bugzilla.suse.com/1286403
bugzilla.suse.com/1286404
bugzilla.suse.com/1286405
bugzilla.suse.com/1286406
bugzilla.suse.com/1286408
bugzilla.suse.com/1286411
bugzilla.suse.com/1286489
bugzilla.suse.com/1286796
bugzilla.suse.com/1286797
bugzilla.suse.com/1286798
bugzilla.suse.com/1286801
bugzilla.suse.com/1286802
bugzilla.suse.com/1286804
suse.com/security/cve/CVE-2026-112390
suse.com/security/cve/CVE-2026-112391
suse.com/security/cve/CVE-2026-112392
suse.com/security/cve/CVE-2026-112393
suse.com/security/cve/CVE-2026-112394
suse.com/security/cve/CVE-2026-112397
suse.com/security/cve/CVE-2026-112398
suse.com/security/cve/CVE-2026-112399
suse.com/security/cve/CVE-2026-112400
suse.com/security/cve/CVE-2026-112401
suse.com/security/cve/CVE-2026-112402
suse.com/security/cve/CVE-2026-112403
suse.com/security/cve/CVE-2026-112405
suse.com/security/cve/CVE-2026-112406
suse.com/security/cve/CVE-2026-112891
suse.com/security/cve/CVE-2026-112892
suse.com/security/cve/CVE-2026-112894
suse.com/security/cve/CVE-2026-112895
suse.com/security/cve/CVE-2026-112896
suse.com/security/cve/CVE-2026-112897
suse.com/security/cve/CVE-2026-112899
suse.com/security/cve/CVE-2026-112900
suse.com/security/cve/CVE-2026-112901
suse.com/security/cve/CVE-2026-112902
suse.com/security/cve/CVE-2026-96636
suse.com/security/cve/CVE-2026-96637
suse.com/security/cve/CVE-2026-96640
suse.com/security/cve/CVE-2026-96641
suse.com/security/cve/CVE-2026-96642
ubuntu.com/security/CVE-2026-112400
cve.org/CVERecord?id=CVE-2026-112400
suse.com/security/cve/CVE-2026-112396
suse.com/security/cve/CVE-2026-112404
suse.com/security/cve/CVE-2026-112898
Left out here: the rest of 2 source descriptions. The JSON record has them.