A YCbCr TIFF subsampled four to one overflows a libtiff buffer

Signed integer overflow in putcontig8bitYCbCr44tile leads to an out-of-bounds heap write.

Advisory

CVE-2026-4775 (also GHSA-cm99-m826-vgg7)

Library

libtiff, tiff on Debian

Published

2026-03-24

Severity

7.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

Opening a YCbCr TIFF whose chroma subsampling is 4x4, through the RGBA reading path.

What sillybos does

Refused by default

sillybos refuses the triggering file under its default policy, through the tiff_subsamplings check.

A YCbCr TIFF's subsampling is a directory tag. The default policy allows 1x1, 2x1, 1x2 and 2x2, which is what scanners and cameras write; 4x4 and the other factor-of-four values are refused.

Proved by this test in the sillybos suite, which builds the triggering file from bytes and checks that it is refused:

• tests/test_check.py::TestHostileFiles::test_a_ycbcr_tiff_subsampled_four_by_four

How to protect yourself

In general. Keep libtiff current.

Specifically. Allow only the subsamplings your files use; sillybos --tiff-subsamplings.

The general advice applies to every row here.

Sources

• https://github.com/advisories/GHSA-cm99-m826-vgg7
• The record entry, triaged 2026-11-01, last checked 2026-11-01