{"id":"CVE-2026-96639","aliases":["BIT-pillow-2026-96639","CLSA-2026-1792743656","CLSA-2026-1792752131","DEBIAN-CVE-2026-96639","EUVD-2026-107573","GHSA-v9pv-5gc8-w2m6","PYSEC-2026-4339","UBUNTU-CVE-2026-96639","openSUSE-SU-2026:22246-1"],"status":"published","title":"Pillow multi-frame loaders can reuse stale native image storage after mode transitions","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","severity":{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00659,"percentile":0.52034,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-125","CWE-787"],"published":"2026-10-21T21:06:42Z","modified":"2026-11-11T17:27:07Z","fixes":[{"ecosystem":"PyPI","package":"pillow","fixed_in":["13.0.0"],"sources":["ghsa","osv"]},{"ecosystem":"Bitnami","package":"pillow","fixed_in":["13.0.0"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"11.0.0"},{"fixed":"13.0.0"}]}]},{"source":"osv","ecosystem":"Bitnami","package":"pillow","ranges":[{"type":"SEMVER","events":[{"introduced":"11.0.0"},{"fixed":"13.0.0"}]}]},{"source":"osv","ecosystem":"TuxCare:PyPI","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"11.3.0"},{"fixed":"11.3.0.post9+tuxcare"}]}],"versions":["11.3.0","11.3.0.post1+tuxcare","11.3.0.post2+tuxcare","11.3.0.post3+tuxcare","11.3.0.post4+tuxcare","11.3.0.post5+tuxcare","11.3.0.post6+tuxcare","11.3.0.post7+tuxcare","11.3.0.post8+tuxcare"],"bundled":6},{"source":"osv","ecosystem":"TuxCare:PyPI","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"11.2.1"},{"fixed":"11.2.1.post11+tuxcare"}]}],"versions":["11.2.1","11.2.1.post1+tuxcare","11.2.1.post10+tuxcare","11.2.1.post2+tuxcare","11.2.1.post3+tuxcare","11.2.1.post4+tuxcare","11.2.1.post5+tuxcare","11.2.1.post6+tuxcare","11.2.1.post7+tuxcare","11.2.1.post8+tuxcare","11.2.1.post9+tuxcare"],"bundled":6},{"source":"osv","ecosystem":"Debian:12","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["10.0.0-1","10.1.0-1","10.2.0-1","10.3.0-1","10.3.0-2","10.4.0-1","10.4.0-1.1","11.1.0-1","11.1.0-2","11.1.0-3","11.1.0-4","11.1.0-5","11.2.1-1","11.3.0-1","12.0.0-1","12.1.0-1","12.1.1-1","12.1.1-2","12.2.0-1","12.3.0-1","13.0.0-1","9.4.0-1.1","9.4.0-1.1+deb12u1","9.5.0-1"]},{"source":"osv","ecosystem":"Debian:13","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["11.1.0-5","11.1.0-5+deb13u1","11.1.0-5+deb13u2","11.1.0-5+deb13u3","11.1.0-5+deb13u4","11.2.1-1","11.3.0-1","12.0.0-1","12.1.0-1","12.1.1-1","12.1.1-2","12.2.0-1","12.3.0-1","13.0.0-1"]},{"source":"osv","ecosystem":"Debian:14","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["11.1.0-5","11.2.1-1","11.3.0-1","12.0.0-1","12.1.0-1","12.1.1-1","12.1.1-2","12.2.0-1","12.3.0-1","13.0.0-1"]},{"source":"osv","ecosystem":"PyPI","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"11.0.0"},{"fixed":"13.0.0"}]}],"versions":["11.0.0","11.1.0","11.2.1","11.3.0","12.0.0","12.1.0","12.1.1","12.2.0","12.3.0"]},{"source":"osv","ecosystem":"PyPI","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"11.0.0"},{"fixed":"13.0.0"}]}],"versions":["11.0.0","11.1.0","11.2.1","11.3.0","12.0.0","12.1.0","12.1.1","12.2.0","12.3.0"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"pillow-python2","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["6.2.1-3~build1","6.2.1-3","6.2.1-3ubuntu0.1~esm1","6.2.1-3ubuntu0.1~esm2"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["12.1.1-2ubuntu1","12.3.0-1ubuntu1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["11.3.0-1ubuntu1","11.3.0-1ubuntu2","12.0.0-1ubuntu1","12.1.1-1ubuntu1","12.1.1-2ubuntu1","12.1.1-2ubuntu1.1","12.1.1-2ubuntu1.2","12.1.1-2ubuntu1.3","12.1.1-2ubuntu1.4"]},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"python-Pillow","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"11.3.0-160000.9.1"}]}],"bundled":39}],"products":[{"vendor":"python","product":"pillow"},{"vendor":"python-pillow","product":"pillow"}],"references":[{"url":"https://github.com/python-pillow/Pillow/security/advisories/GHSA-v9pv-5gc8-w2m6","tags":["x_refsource_CONFIRM","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/python-pillow/Pillow/pull/10105","tags":["x_refsource_MISC","Issue Tracking","report","fix","web"]},{"url":"https://github.com/python-pillow/Pillow/commit/78d97d994579aef81aafe123773d525f40f2522a","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/python-pillow/Pillow/releases/tag/13.0.0","tags":["x_refsource_MISC","Release Notes","article","web","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-96639","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-v9pv-5gc8-w2m6"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/96xxx/CVE-2026-96639.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-96639","tags":["advisory"]},{"url":"https://github.com/python-pillow/Pillow","tags":["package"]},{"url":"https://ubuntu.com/security/CVE-2026-96639","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-96639","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1286256","tags":["report"]},{"url":"https://bugzilla.suse.com/1286273","tags":["report"]},{"url":"https://bugzilla.suse.com/1286287","tags":["report"]},{"url":"https://bugzilla.suse.com/1286311","tags":["report"]},{"url":"https://bugzilla.suse.com/1286312","tags":["report"]},{"url":"https://bugzilla.suse.com/1286313","tags":["report"]},{"url":"https://bugzilla.suse.com/1286314","tags":["report"]},{"url":"https://bugzilla.suse.com/1286325","tags":["report"]},{"url":"https://bugzilla.suse.com/1286368","tags":["report"]},{"url":"https://bugzilla.suse.com/1286370","tags":["report"]},{"url":"https://bugzilla.suse.com/1286372","tags":["report"]},{"url":"https://bugzilla.suse.com/1286381","tags":["report"]},{"url":"https://bugzilla.suse.com/1286388","tags":["report"]},{"url":"https://bugzilla.suse.com/1286392","tags":["report"]},{"url":"https://bugzilla.suse.com/1286396","tags":["report"]},{"url":"https://bugzilla.suse.com/1286397","tags":["report"]},{"url":"https://bugzilla.suse.com/1286398","tags":["report"]},{"url":"https://bugzilla.suse.com/1286399","tags":["report"]},{"url":"https://bugzilla.suse.com/1286400","tags":["report"]},{"url":"https://bugzilla.suse.com/1286401","tags":["report"]},{"url":"https://bugzilla.suse.com/1286402","tags":["report"]},{"url":"https://bugzilla.suse.com/1286403","tags":["report"]},{"url":"https://bugzilla.suse.com/1286404","tags":["report"]},{"url":"https://bugzilla.suse.com/1286405","tags":["report"]},{"url":"https://bugzilla.suse.com/1286406","tags":["report"]},{"url":"https://bugzilla.suse.com/1286408","tags":["report"]},{"url":"https://bugzilla.suse.com/1286411","tags":["report"]},{"url":"https://bugzilla.suse.com/1286489","tags":["report"]},{"url":"https://bugzilla.suse.com/1286793","tags":["report"]},{"url":"https://bugzilla.suse.com/1286795","tags":["report"]},{"url":"https://bugzilla.suse.com/1286796","tags":["report"]},{"url":"https://bugzilla.suse.com/1286797","tags":["report"]},{"url":"https://bugzilla.suse.com/1286798","tags":["report"]},{"url":"https://bugzilla.suse.com/1286799","tags":["report"]},{"url":"https://bugzilla.suse.com/1286800","tags":["report"]},{"url":"https://bugzilla.suse.com/1286801","tags":["report"]},{"url":"https://bugzilla.suse.com/1286802","tags":["report"]},{"url":"https://bugzilla.suse.com/1286803","tags":["report"]},{"url":"https://bugzilla.suse.com/1286804","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112390","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112391","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112392","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112393","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112394","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112395","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112396","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112397","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112398","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112399","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112400","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112401","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112402","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112403","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112404","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112405","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112406","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112891","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112892","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112893","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112894","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112895","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112896","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112897","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112898","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112899","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112900","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112901","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-112902","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-114501","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96636","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96637","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96638","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96639","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96640","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96641","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96642","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96643","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-96778","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-96639","title":"Pillow multi-frame loaders can reuse stale native image storage after mode transitions","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-21T21:06:42.111Z","modified":"2026-10-29T10:51:37.735Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"cna"}],"cwes":["CWE-125","CWE-787"],"updated_at":"2026-11-02T14:20:00.879257Z"}],"euvd":[{"id":"EUVD-2026-107573","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-21T21:06:42Z","modified":"2026-10-29T10:51:37Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T16:59:17.279653Z"}],"ghsa":[{"id":"GHSA-v9pv-5gc8-w2m6","title":"Pillow multi-frame loaders can reuse stale native image storage after mode transitions","description":"### Summary\nPillow multi-frame image loaders can retain native `ImagingCore` storage allocated for one frame while changing the Python-side image `mode` and decoder tiles for a later frame.\n\nIf frame 0 allocates storage for a narrow mode such as `L`, and a later frame of the same dimensions switches to a wider mode such as `RGB` or `CMYK`, Pillow may decode wider pixels into the stale narrow native buffer. This causes native\nout-of-bounds writes and process crashes. In the MPO/JPEG path, I also demonstrated command execution in matching Python/Pillow runtime profiles through Pillow's documented `ImageSequence.Iterator` + `frame.load()` path.\n\n### Details\nThe root cause appears to be that `ImageFile.load_prepare()` only reallocates native storage when `_im is None`. It does not verify that the retained native `ImagingCore` storage still matches `self.mode` and `self.size`.\n\nSeveral multi-frame `seek()` / `_open()` paths can update `self._mode` and decoder tiles for a later frame without invalidating `_im`. The decoder then writes or reads according to the new frame mode while the native storage still belongs to the old frame mode.\n\nVerified affected surfaces:\n\n1. **PSD**\n\n   `PsdImageFile.seek()` can switch from grayscale/native `L` storage to RGB layer decoding while retaining `_im`. This produces attacker-controlled native out-of-bounds writes and reliable crashes.\n\n2. **MPO/JPEG**\n\n   A crafted two-frame MPO can make frame 0 allocate `L` storage, then make frame 1 decode `CMYK` / `RGB` data into the retained `L` storage. The documented `ImageSequence.Iterator` path reaches this with `frame.load()`.\n   Verified native memory corruption, crash, over-read behavior, and scoped harmless-marker command execution on Pillow 12.3.0.\n\n3. **DCX**\n\n   `DcxImageFile.seek()` calls `PcxImageFile._open()`, which changes mode/tile  state without a native-storage mode guard. A crafted DCX with `L` then `RGB` PCX frames produces retained-storage mismatch and crash.\n\n4. **MIC**\n\n   MIC can call `TiffImageFile._open()` directly and bypass TIFF's normal guarded `seek()` behavior. With a `NextIFD`-based reachable frame transition, this produces retained-storage mismatch and crash.\n\nTIFF appears to be a useful positive control because its `seek()` path checks\nboth size and mode before reusing storage.\n\n### Impact\n- process crash / denial of service,\n- native out-of-bounds write,\n- native over-read in the MPO path.\n\nStronger proven impact:\n\n- command execution in matching Python/Pillow runtime profiles through the MPO/JPEG path.\n\nServer-side deployment impact:\n\n- Create a local vulnerable web upload service that accepts an unauthenticated MPO upload and automatically processes it with Pillow.\n- The attack is one HTTP request and requires no user interaction after upload.\n- The fixed harmless command-output marker succeeded 10/10 times.\n- The `_im=None` control was clean 10/10 times.\n\n\n## Reproduction Evidence\n\nTested version:\n\n```text\nPillow 12.3.0\n```\n\nMPO terminal proof environments:\n\n```text\nPython 3.12.3 + Pillow 12.3.0, clean PyPI environment:\nmarker 10/10, control 0/10\n\nPython 3.13.14 + Pillow 12.3.0, prepared profile:\nmarker 10/10, control 0/10\n```\n\nServer-side web-upload proof:\n\n```text\ncontrol 1..10: MARKER_MISSING\ncontrol_summary ok 0 missing 10 /10\n\nvulnerable 1..10: MARKER_OK marker_output \u003cserver-user\u003e\nvulnerable_summary ok 10 missing 0 /10\n```\n\nThe terminal proof uses a fixed harmless marker command only. It does not use a reverse shell, persistence, data exfiltration, or arbitrary attacker-selected commands.\n\nI can provide the following private artifacts to maintainers:\n\n- minimal crash fixtures for PSD, MPO, DCX, and MIC,\n- non-weaponized MPO marker PoC,\n- local vulnerable web upload demo,\n- gdb/GEF geometry receipts,\n- control-run logs,\n- proposed regression-test shape.\n\n## Minimal Reproduction Shape\n\nFor the MPO path, the vulnerable consumer shape is:\n\n```python\nfrom io import BytesIO\nfrom PIL import Image, ImageSequence\n\nsource = BytesIO(open(path, \"rb\").read())\nimage = Image.open(source)\niterator = ImageSequence.Iterator(image)\nnext(iterator).load()\nnext(iterator).load()\n```\n\nThe crafted image shape is:\n\n```text\nframe 0: mode L, dimensions W x H\nframe 1: same W x H, wider mode such as CMYK\n```\n\nFrame 0 allocates native `L` storage. Frame 1 changes the logical mode and decoder state but can reuse the old native storage. The frame 1 decoder writes using the wider mode into the narrow storage.\n\n## Suggested Fix Direction\n\nBefore reusing native `ImagingCore` storage, Pillow should verify that the retained storage is compatible with the current logical image mode and size.\n\nA central guard in `ImageFile.load_prepare()` could compare native storage mode/size against `self.mode` / `self.size` and allocate fresh storage when they differ. Alternatively, every mode-changing `seek()` / `_open()` path should explicitly invalidate `_im` before decoding.\n\nCaution: TIFF has specialized tile-size behavior and already has a mode/size guard, so a central fix should avoid regressing TIFF tile-buffer handling.\n\n\n## Credit\n\n```text\nRotem Kama\n```\n\n## Methodology Note\n\nAI-assisted analysis was used for discovery and verification support. Claims in this report are limited to the local artifacts, controls, and command outputs described above.","status":"published","published":"2026-10-22T16:00:15Z","modified":"2026-10-22T16:00:15Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-125","CWE-787"],"updated_at":"2026-11-02T14:41:34.690842Z"}],"nvd":[{"id":"CVE-2026-96639","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-21T21:20:32.217Z","modified":"2026-10-29T11:17:39.023Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical","assessor":"secondary"}],"cwes":["CWE-125","CWE-787"],"updated_at":"2026-11-02T14:13:02.371082Z"}],"osv":[{"id":"CVE-2026-96639","title":"Pillow multi-frame loaders can reuse stale native image storage after mode transitions","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-21T21:06:42.111Z","modified":"2026-11-11T17:27:07.058341959Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-125","CWE-787"],"updated_at":"2026-11-11T17:46:33.10646Z"},{"id":"DEBIAN-CVE-2026-96639","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-21T21:20:32.217Z","modified":"2026-10-30T09:49:14.278193595Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T15:46:07.324252Z"},{"id":"GHSA-v9pv-5gc8-w2m6","title":"Pillow multi-frame loaders can reuse stale native image storage after mode transitions","description":"### Summary\nPillow multi-frame image loaders can retain native `ImagingCore` storage allocated for one frame while changing the Python-side image `mode` and decoder tiles for a later frame.\n\nIf frame 0 allocates storage for a narrow mode such as `L`, and a later frame of the same dimensions switches to a wider mode such as `RGB` or `CMYK`, Pillow may decode wider pixels into the stale narrow native buffer. This causes native\nout-of-bounds writes and process crashes. In the MPO/JPEG path, I also demonstrated command execution in matching Python/Pillow runtime profiles through Pillow's documented `ImageSequence.Iterator` + `frame.load()` path.\n\n### Details\nThe root cause appears to be that `ImageFile.load_prepare()` only reallocates native storage when `_im is None`. It does not verify that the retained native `ImagingCore` storage still matches `self.mode` and `self.size`.\n\nSeveral multi-frame `seek()` / `_open()` paths can update `self._mode` and decoder tiles for a later frame without invalidating `_im`. The decoder then writes or reads according to the new frame mode while the native storage still belongs to the old frame mode.\n\nVerified affected surfaces:\n\n1. **PSD**\n\n   `PsdImageFile.seek()` can switch from grayscale/native `L` storage to RGB layer decoding while retaining `_im`. This produces attacker-controlled native out-of-bounds writes and reliable crashes.\n\n2. **MPO/JPEG**\n\n   A crafted two-frame MPO can make frame 0 allocate `L` storage, then make frame 1 decode `CMYK` / `RGB` data into the retained `L` storage. The documented `ImageSequence.Iterator` path reaches this with `frame.load()`.\n   Verified native memory corruption, crash, over-read behavior, and scoped harmless-marker command execution on Pillow 12.3.0.\n\n3. **DCX**\n\n   `DcxImageFile.seek()` calls `PcxImageFile._open()`, which changes mode/tile  state without a native-storage mode guard. A crafted DCX with `L` then `RGB` PCX frames produces retained-storage mismatch and crash.\n\n4. **MIC**\n\n   MIC can call `TiffImageFile._open()` directly and bypass TIFF's normal guarded `seek()` behavior. With a `NextIFD`-based reachable frame transition, this produces retained-storage mismatch and crash.\n\nTIFF appears to be a useful positive control because its `seek()` path checks\nboth size and mode before reusing storage.\n\n### Impact\n- process crash / denial of service,\n- native out-of-bounds write,\n- native over-read in the MPO path.\n\nStronger proven impact:\n\n- command execution in matching Python/Pillow runtime profiles through the MPO/JPEG path.\n\nServer-side deployment impact:\n\n- Create a local vulnerable web upload service that accepts an unauthenticated MPO upload and automatically processes it with Pillow.\n- The attack is one HTTP request and requires no user interaction after upload.\n- The fixed harmless command-output marker succeeded 10/10 times.\n- The `_im=None` control was clean 10/10 times.\n\n\n## Reproduction Evidence\n\nTested version:\n\n```text\nPillow 12.3.0\n```\n\nMPO terminal proof environments:\n\n```text\nPython 3.12.3 + Pillow 12.3.0, clean PyPI environment:\nmarker 10/10, control 0/10\n\nPython 3.13.14 + Pillow 12.3.0, prepared profile:\nmarker 10/10, control 0/10\n```\n\nServer-side web-upload proof:\n\n```text\ncontrol 1..10: MARKER_MISSING\ncontrol_summary ok 0 missing 10 /10\n\nvulnerable 1..10: MARKER_OK marker_output \u003cserver-user\u003e\nvulnerable_summary ok 10 missing 0 /10\n```\n\nThe terminal proof uses a fixed harmless marker command only. It does not use a reverse shell, persistence, data exfiltration, or arbitrary attacker-selected commands.\n\nI can provide the following private artifacts to maintainers:\n\n- minimal crash fixtures for PSD, MPO, DCX, and MIC,\n- non-weaponized MPO marker PoC,\n- local vulnerable web upload demo,\n- gdb/GEF geometry receipts,\n- control-run logs,\n- proposed regression-test shape.\n\n## Minimal Reproduction Shape\n\nFor the MPO path, the vulnerable consumer shape is:\n\n```python\nfrom io import BytesIO\nfrom PIL import Image, ImageSequence\n\nsource = BytesIO(open(path, \"rb\").read())\nimage = Image.open(source)\niterator = ImageSequence.Iterator(image)\nnext(iterator).load()\nnext(iterator).load()\n```\n\nThe crafted image shape is:\n\n```text\nframe 0: mode L, dimensions W x H\nframe 1: same W x H, wider mode such as CMYK\n```\n\nFrame 0 allocates native `L` storage. Frame 1 changes the logical mode and decoder state but can reuse the old native storage. The frame 1 decoder writes using the wider mode into the narrow storage.\n\n## Suggested Fix Direction\n\nBefore reusing native `ImagingCore` storage, Pillow should verify that the retained storage is compatible with the current logical image mode and size.\n\nA central guard in `ImageFile.load_prepare()` could compare native storage mode/size against `self.mode` / `self.size` and allocate fresh storage when they differ. Alternatively, every mode-changing `seek()` / `_open()` path should explicitly invalidate `_im` before decoding.\n\nCaution: TIFF has specialized tile-size behavior and already has a mode/size guard, so a central fix should avoid regressing TIFF tile-buffer handling.\n\n\n## Credit\n\n```text\nRotem Kama\n```\n\n## Methodology Note\n\nAI-assisted analysis was used for discovery and verification support. Claims in this report are limited to the local artifacts, controls, and command outputs described above.","status":"published","published":"2026-10-22T16:00:15Z","modified":"2026-10-29T10:55:37.663049285Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"cwes":["CWE-125","CWE-787"],"updated_at":"2026-11-02T15:46:56.981655Z"},{"id":"PYSEC-2026-4339","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-21T21:20:32.217Z","modified":"2026-10-29T10:55:37.663049285Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-02T15:52:57.671918Z"},{"id":"UBUNTU-CVE-2026-96639","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-21T21:20:00Z","modified":"2026-11-04T20:04:29.566043469Z","cvss":[{"version":"3.1","score":9.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","level":"critical"}],"updated_at":"2026-11-04T21:43:26.87909Z"},{"id":"BIT-pillow-2026-96639","title":"Pillow multi-frame loaders can reuse stale native image storage after mode transitions","description":"Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.","status":"published","published":"2026-10-29T08:58:14.316Z","modified":"2026-10-29T10:55:37.663049285Z","updated_at":"2026-11-02T15:28:34.724063Z"},{"id":"CLSA-2026-1792743656","title":"TuxCare security update for pillow (6 CVEs)","description":"TuxCare rebuilt pillow to address 6 CVEs. Fixed in 11.3.0.post9+tuxcare.","status":"published","published":"2026-10-23T08:20:56Z","modified":"2026-10-23T13:45:07.720437274Z","updated_at":"2026-11-02T15:43:54.981307Z"},{"id":"CLSA-2026-1792752131","title":"TuxCare security update for pillow (6 CVEs)","description":"TuxCare rebuilt pillow to address 6 CVEs. Fixed in 11.2.1.post11+tuxcare.","status":"published","published":"2026-10-23T10:42:11Z","modified":"2026-10-23T13:45:07.5154934Z","updated_at":"2026-11-02T15:43:54.981307Z"},{"id":"openSUSE-SU-2026:22246-1","title":"Security update for python-Pillow","description":"This update for python-Pillow fixes the following issues:\n\n- CVE-2026-96636: decompression-bomb protection bypass via multi-frame `seek()` in MPO and DCX (bsc#1286802).\n- CVE-2026-96637: decompression bomb check bypass in `SpiderImagePlugin.seek()` leads to unbounded allocation DoS\n  (bsc#1286801).\n- CVE-2026-96638: BMP RLE decoder memory-amplification DoS via unbounded delta escape/absolute mode (bsc#1286800).\n- CVE-2026-96639: multi-frame loaders can reuse stale native image storage after mode transitions (bsc#1286799).\n- CVE-2026-96640: PDF append accepts malformed shared page-tree DAG, which can cause resource exhaustion (bsc#1286798).\n- CVE-2026-96641: reachable undefined behavior in native integer operations can lead to denial of service or logic\n  integrity compromise (bsc#1286797).\n- CVE-2026-96642: `TarIO` negative size field causes infinite CPU-spin loop (bsc#1286796).\n- CVE-2026-96643: PNG eXIf chunk makes EXIF parsing run in quadratic time (bsc#1286795).\n- CVE-2026-96778: heap buffer overflow writing JPEG comment after ICC profile fills buffer (bsc#1286793).\n- CVE-2026-112390: Denial of Service via infinite loop during crafted MIC image parsing (bsc#1286256).\n- CVE-2026-112391: Denial of Service via unbounded recursion in PDF parser (bsc#1286273).\n- CVE-2026-112392: Denial of Service via zero-size images in rank filters (bsc#1286287).\n- CVE-2026-112393: heap buffer overflow and stale-heap disclosure in _tiffWriteProc when saving compressed TIFF data\n  (bsc#1286325).\n- CVE-2026-112394: `P;2L` and `P;4L` decoders may read 1 to 3 bytes past the passed buffer size (bsc#1286311).\n- CVE-2026-112395: Pillow tiled-TIFF decoder reads past tile buffer in `copy4` (bsc#1286312).\n- CVE-2026-112396: heap use-after-free when encoding TIFF to an in-memory buffer (bsc#1286313).\n- CVE-2026-112397: out-of-bounds access in `_imagingmorph` on a zero-width image (bsc#1286314).\n- CVE-2026-112398: heap buffer overflow in FPX JPEG decoding can lead to code execution (bsc#1286406).\n- CVE-2026-112399: Denial of service via crafted APNG image (bsc#1286368).\n- CVE-2026-112400: Denial of Service via memory exhaustion from crafted GIF image (bsc#1286370).\n- CVE-2026-112401: Denial of Service via crafted GIF comments (bsc#1286372).\n- CVE-2026-112402: Denial of service via double free during image transformation (bsc#1286381).\n- CVE-2026-112403: heap buffer overflow in `ImagingJpegDecode` allows for code execution (bsc#1286405).\n- CVE-2026-112404: Denial of Service via out-of-bounds read in TIFF decoding (bsc#1286388).\n- CVE-2026-112405: NULL pointer dereference in `Image.merge` via an unvalidated band 0 (bsc#1286404).\n- CVE-2026-112406: infinite loop in `PdfParser.rewrite_pages` on page tree `Parent` cycle (bsc#1286403).\n- CVE-2026-112891: quadratic GIF comment copying during save (bsc#1286402).\n- CVE-2026-112892: MSP RLE decoder expands a tiny file into unbounded memory (bsc#1286401).\n- CVE-2026-112893: Denial of Service via invalid pointer free during font rendering (bsc#1286392).\n- CVE-2026-112894: Denial of Service via crafted multi-frame image conversion (bsc#1286408).\n- CVE-2026-112895: Denial of service via crafted PDF during append operations (bsc#1286411).\n- CVE-2026-112896: TIFF encoder `ColorMap` plane-size mismatch causes a heap out-of-bounds read (bsc#1286400).\n- CVE-2026-112897: `TiffDecode` returns uninitialized memory as pixels for short JPEG strips (bsc#1286398).\n- CVE-2026-112898: `Image.quantize()` with empty palette can leak uninitialized stack memory (bsc#1286399).\n- CVE-2026-112899: EPS `load(scale)` lets Ghostscript render past the decompression bomb limit (bsc#1286489).\n- CVE-2026-112900: argument Injection in Ghostscript call can lead to remote code execution (bsc#1286397).\n- CVE-2026-112901: ReDoS in `XbmImagePlugin` can be triggered by 512-byte file (bsc#1286396).\n- CVE-2026-112902: memory disclosure and segfault in libtiff encoder via crafted TIFF tags (bsc#1286804).\n- CVE-2026-114501: Arrow export leaks stale heap memory when `PILLOW_ALIGNMENT \u003e 1` (bsc#1286803).\n","status":"published","published":"2026-11-05T03:40:19Z","modified":"2026-11-11T17:23:13.17320283Z","updated_at":"2026-11-11T17:47:15.466074Z"}]}}