A later frame of an MPO or DCX file is never checked against the pixel limit
The decompression-bomb check runs only on the first frame; MpoImageFile.seek() and DcxImageFile.seek() do not repeat it.
- Advisory
- CVE-2026-96636 (also GHSA-p8hx-v2p6-rp84)
- Library
- Pillow, pillow on PyPI
- Published
- Severity
- 6.5 out of 10, as published
- Affected
- < 13.0.0
- Fixed in
- 13.0.0
- Reaches you
- by opening a file
What triggers it
Seeking to a later frame of a multi-picture JPEG, or a DCX file, whose first frame is tiny and whose later frame declares enormous dimensions.
What sillybos does
Refused by default
sillybos refuses the triggering file under its default policy, through the max_pixels check.
Every picture of a multi-picture JPEG is read from the index and each held to max_pixels. DCX is not a known format and is refused as unknown.
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_multi_picture_jpeg_whose_second_picture_is_a_bombtests/test_check.py::TestHostileFiles::test_an_unknown_format
How to protect yourself
In general. Upgrade to Pillow 13.0.0.
Specifically. Apply the pixel limit to every frame, not the first; sillybos does.
The general advice applies to every row here.
Sources
- https://github.com/advisories/GHSA-p8hx-v2p6-rp84
- The record entry, triaged 2026-11-01, last checked 2026-11-01