Saving a GIF with a long comment copies it in quadratic time
Pillow: Quadratic GIF comment copying during save
- Advisory
- CVE-2026-112891
- Library
- Pillow, pillow on PyPI
- Published
- Severity
- not scored upstream
- Affected
- 12.3.0
- Fixed in
- see the upstream record
- Reaches you
- on a save path
What triggers it
Image.save(format="GIF") of an image carrying a long comment.
What sillybos does
Refused with a setting
sillybos refuses the triggering file when the policy says so (Policy(max_metadata_bytes=65_536)); the default policy lets it through.
The comment rides from the opened file into a GIF save on its own. From a file it can only come through a PNG text chunk, since a JPEG comment segment is at most 65,533 bytes by format, too short to matter, and a GIF is refused by name. The chunk is a block the reader measures: the default ceiling of 4 MiB allows a comment long enough to cost tens of seconds, and a lower ceiling bounds it.
Proposed from the advisory's text on 2026-11-01, as part of folding the backfill into the record; confirmed by a person on 2026-11-03. Re-read on 2026-11-03 against the question of what rides from an opened file into a save: the file is the input.
Proved by this test in the sillybos suite, which builds the triggering file from bytes and checks that it is refused:
How to protect yourself
In general. Upgrade Pillow to a version that has the fix; the upstream record names it.
Specifically. Set max_metadata_bytes to what a scan carries, tens of kilobytes, where images from outside are re-saved as GIF; upgrade to a Pillow with the fix.
The general advice applies to every row here.
Sources
- https://osv.dev/vulnerability/GHSA-fc9g-5qg7-mf45
- The record entry, triaged 2026-11-03, last checked 2026-11-03