CVE-2025-9900

What it actually does

write-what-where memory corruption triggered by an abnormally large image height value in TIFF metadata, allowing attacker-controlled color data to be written to an arbitrary memory location

Why it matters to the business

applications processing untrusted TIFF images may crash or allow arbitrary code execution under the privileges of the processing user; the flaw affects downstream packages in container ecosystems with moderate prevalence, and remediation deadlines have passed without widespread exploitation observed

How an attack unfolds

an attacker crafts a TIFF file containing an oversized height field in its metadata, supplies the file to any application linked against the vulnerable libtiff code path, and leverages the resulting write-what-where primitive to corrupt memory for denial of service or to redirect execution to attacker-supplied code

How to fix it

upgrade protoc-gen-go-grpc (Chainguard) and protoc-gen-go-grpc (Wolfi) to version 1.5.1-r2 or later; rebuild and redeploy any containers or packages that embed the vulnerable libtiff dependency

How to confirm the fix worked

verify installed package versions match or exceed the fixed releases, run regression tests with known-bad TIFF samples, and confirm absence of the oversized-height code path in loaded libraries

Typical attack path

1. attacker generates a malicious TIFF with inflated ImageLength metadata
2. victim application or library opens the file using the affected libtiff routines
3. library performs an out-of-bounds write of color data to a computed memory address
4. memory corruption leads to crash or is further exploited for code execution

How to detect it

review application and library logs for crashes or segmentation faults during TIFF processing, monitor for unexpected memory writes or child-process spawns after image handling, and inspect file-upload or conversion workflows for recent malformed TIFF files

What your security team should do

• immediately update all instances of the listed packages to the stated fixed versions
• scan container registries and build pipelines for any older builds still referencing vulnerable libtiff
• add TIFF file validation or sandboxing for any remaining image-processing workflows until patches are applied