A multi-frame file that changes colour mode writes into a buffer sized for the first frame
Multi-frame loaders can reuse stale native image storage after a mode transition, giving out-of-bounds writes; command execution was demonstrated through the MPO path.
- Advisory
- CVE-2026-96639 (also GHSA-v9pv-5gc8-w2m6)
- Library
- Pillow, pillow on PyPI
- Published
- Severity
- 9.8 out of 10, as published
- Affected
- >= 11.0.0, < 13.0.0
- Fixed in
- 13.0.0
- Reaches you
- by opening a file
What triggers it
Iterating the frames of a crafted multi-picture JPEG (MPO), TIFF or Photoshop file whose later frame is a wider colour mode than the first.
What sillybos does
Refused by default
sillybos refuses the triggering file under its default policy, through the headers check.
Every frame of a TIFF and every picture of a multi-picture JPEG is read and required to match the first in colour mode, samples and bit depth; a file that changes is refused. Photoshop files are refused by format.
Proved by these tests in the sillybos suite, each of which builds the triggering file from bytes and checks that it is refused:
tests/test_check.py::TestHostileFiles::test_a_tiff_that_changes_mode_between_framestests/test_check.py::TestHostileFiles::test_a_multi_picture_jpeg_that_changes_mode
How to protect yourself
In general. Upgrade to Pillow 13.0.0.
Specifically. Require every frame of a multi-frame file to share the first frame's mode and size before decoding; sillybos does.
The general advice applies to every row here.
Sources
- https://github.com/advisories/GHSA-v9pv-5gc8-w2m6
- The record entry, triaged 2026-11-01, last checked 2026-11-01