Every CVE Search/ Get API key

CVE-2026-112400

Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS

8.7 HighFix available

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

0.59%Up 0.3 points since Oct 20, 2026
90%50%10%1%

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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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 HighCVSS: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: TarIO negative 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;2L and P;4L decoders may read 1 to 3 bytes past the passed buffer size (bsc#1286311).
  • CVE-2026-112397: out-of-bounds access in _imagingmorph on 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 ImagingJpegDecode allows for code execution (bsc#1286405).
  • CVE-2026-112405: NULL pointer dereference in Image.merge via an unvalidated band 0 (bsc#1286404).
  • CVE-2026-112406: infinite loop in PdfParser.rewrite_pages on page tree Parent cycle (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 ColorMap plane-size mismatch causes a heap out-of-bounds read (bsc#1286400).
  • CVE-2026-112897: TiffDecode returns 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 XbmImagePlugin can 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

Affected packages
PackageAffectedFixed
pillow
PyPI
9.2.0 up to 13.0.0
13.0.0
pillow
Bitnami
9.2.0 up to 13.0.0
13.0.0
pillow
TuxCare: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
pillow
TuxCare: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
pillow
TuxCare: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 less
10.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
pillow
TuxCare: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
pillow
TuxCare: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 less
9.4.0.post6+tuxcare9.4.0.post7+tuxcare9.4.0.post8+tuxcare9.4.0.post9+tuxcare
9.4.0.post10+tuxcare
pillow
TuxCare: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 less
8.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
pillow
Debian: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 less
10.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
pillow
Debian: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 less
11.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
Affected packages
PackageAffectedFixed
pillow
Debian: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 less
12.1.1-112.1.1-212.2.0-112.3.0-113.0.0-1
None known
pillow
PyPI
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 less
10.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
pillow
Root: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-Pillow
SUSE: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-python2
Ubuntu: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
pillow
Ubuntu: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
pillow
Ubuntu:26.10
All versions, plus listed versions
12.1.1-2ubuntu112.3.0-1ubuntu1
None known
pillow
Ubuntu: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 less
12.1.1-2ubuntu1.112.1.1-2ubuntu1.212.1.1-2ubuntu1.312.1.1-2ubuntu1.4
None known
python-Pillow
openSUSE:Tumbleweed
From an advisory covering 14 CVEs
before 13.0.0-1.1
13.0.0-1.1

History

History
RecordedChangedSources
affectedOSV
affected
affectedOSV
affectedOSV
affectedOSV
affectedOSV
affected, factsOSV
affected, aliases, referencesOSV
affectedOSV
first indexedCVE 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

Show 66 moreShow less
This page doesn't list everything

Left out here: the rest of 2 source descriptions. The JSON record has them.

MoveEnter Open