An abnormally tall TIFF makes libtiff write colour data to an arbitrary address
A flaw was found in Libtiff.
- Advisory
- CVE-2025-9900
- Library
- libtiff, tiff on Debian
- Published
- Severity
- 8.8 out of 10, as published
- Affected
- LibTIFF, as packaged; see the upstream record
- Fixed in
- see the upstream record
- Reaches you
- by opening a file
What triggers it
Reading a TIFF whose image height is abnormally large, through libtiff's RGBA image reading.
What sillybos does
Refused by default
sillybos refuses the triggering file under its default policy, through the max_side check.
The height is in the first directory, which sillybos reads. A height large enough to carry the pixel count past max_pixels was already refused; a tall, narrow image within the pixel budget was not, until max_side: every page, frame and tile is now held to it on its longest side (30,000 by default; no scanner writes a side longer than a few tens of thousands of pixels).
Proposed from the advisory's text on 2026-11-01, as part of folding the backfill into the record; not yet confirmed by a person.
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 libtiff to a version that has the fix; the upstream record names it.
Specifically. Set max_side from your corpus (the longest side of your largest real page, times two or three); sillybos refuses a taller or wider image before libtiff sees it.
The general advice applies to every row here.
Sources
- https://osv.dev/vulnerability/DEBIAN-CVE-2025-9900
- The record entry, triaged 2026-11-02, last checked 2026-11-02