CVE-2026-4775

What it actually does

CVE-2026-4775 is a memory corruption flaw in libtiff’s handling of specially crafted TIFF images. A signed integer overflow in the putcontig8bitYCbCr44tile function can cause incorrect heap pointer calculations, resulting in an out-of-bounds heap write. In practical terms, software that uses libtiff to parse or transform TIFF files may crash when processing a malicious image, and under favorable memory-layout conditions the flaw may allow arbitrary code execution in the context of the vulnerable application or service.

Why it matters to the business

Organizations that process TIFF files through desktop applications, document management systems, image conversion pipelines, print workflows, web upload features, email gateways, or automated media-processing services may be exposed. Successful exploitation could interrupt image-processing workloads, crash business applications, or potentially allow an attacker to run code with the privileges of the affected process. Although this issue is not listed in CISA KEV, has no known public exploit maturity in the provided data, and has a relatively low EPSS score, libtiff is widely embedded in operating systems and third-party applications, so patching should be prioritized where TIFF files from untrusted sources are processed.

How an attack unfolds

An attacker prepares a malformed TIFF file that triggers the signed integer overflow in libtiff’s YCbCr 4:4 tiled image handling path. The attacker then delivers the file to a target workflow, such as an email attachment, shared file location, web upload endpoint, document ingestion service, image thumbnailer, print service, or other application that uses libtiff. When the vulnerable application opens, previews, indexes, converts, or otherwise parses the file, libtiff reaches putcontig8bitYCbCr44tile and calculates an incorrect memory destination. This can overwrite heap memory outside the intended buffer. The most likely visible result is an application crash, but a carefully engineered exploit could attempt to control the overwrite and execute attacker-controlled code under the privileges of the affected process.

How to fix it

Upgrade libtiff and vendor packages to versions that include the fix when available from the relevant operating system or application vendor. Because no exact fixed versions were provided, use distribution security advisories for Red Hat Enterprise Linux, Debian, Red Hat hardened images, and any bundled third-party applications that ship libtiff. Rebuild or redeploy container images and statically linked applications that include vulnerable libtiff code. Where immediate patching is not possible, reduce exposure by blocking or quarantining TIFF files from untrusted sources, disabling TIFF preview/thumbnail generation where feasible, sandboxing image-processing services, running converters with least privilege, applying memory-safety hardening such as ASLR and compiler hardening, and isolating document-processing workloads from sensitive systems.

How to confirm the fix worked

Confirm remediation by inventorying all installed and bundled libtiff instances, including OS packages, containers, appliances, desktop applications, and statically linked tools. Verify the installed package versions against the latest vendor advisories for the affected distributions and products. Confirm that container base images and hardened images have been rebuilt from patched sources. Test representative TIFF-processing workflows after patching to ensure normal operation. To check exposure, identify services and applications that accept or automatically process TIFF files from users, email, web uploads, shared folders, or external integrations. If safe testing artifacts are available from a trusted vendor or internal security team, validate that patched systems reject or safely process malformed TIFF files without crashing.

Typical attack path

1. Identify an application, service, or workflow that processes TIFF images using a vulnerable libtiff build.
2. Craft a TIFF file with malformed YCbCr 4:4 tiled image data designed to trigger the signed integer overflow.
3. Deliver the file through a path the target is likely to process, such as email, file upload, document ingestion, shared storage, scanning, printing, or media conversion.
4. Wait for the vulnerable application or automated service to parse, preview, thumbnail, convert, or index the TIFF file.
5. Trigger an out-of-bounds heap write in libtiff’s putcontig8bitYCbCr44tile function.
6. Cause a denial-of-service crash or attempt to achieve arbitrary code execution in the context of the affected process.

How to detect it

Review logs and telemetry from systems that process TIFF files, including web upload services, document ingestion platforms, email gateways, file indexing services, thumbnail generators, print workflows, image conversion tools, and desktop applications. Look for crashes or abnormal terminations shortly after TIFF files are opened, uploaded, converted, previewed, or indexed. Useful sources include application logs, systemd journal, syslog, Windows Application event logs, EDR process telemetry, crash reporters, core dump directories, container logs, web access logs for TIFF uploads, and file quarantine/sandbox logs. Investigate segmentation faults, heap corruption messages, allocator aborts, or crashes referencing libtiff, TIFFReadEncodedTile, TIFFRGBAImage, or putcontig8bitYCbCr44tile. Correlate crash timestamps with newly received .tif or .tiff files, external upload source IPs, email senders, or shared-folder writes. Because this vulnerability does not have a stable network signature or known public exploit indicator from the provided data, detection should focus on suspicious TIFF-processing crashes, malicious file provenance, and post-crash behavior such as unexpected child processes, network connections, or file modifications by image-processing applications.

• putcontig8bitYCbCr44tile
• libtiff.so
• libtiff.dll
• TIFFReadEncodedTile
• TIFFRGBAImage
• heap-buffer-overflow
• out-of-bounds heap write
• corrupted size vs. prev_size
• double free or corruption
• malloc(): memory corruption
• free(): invalid pointer
• Segmentation fault
• SIGSEGV
• .tif
• .tiff

What your security team should do

• Inventory libtiff usage across servers, endpoints, containers, image-processing pipelines, document-management systems, print services, and applications that parse TIFF files.
• Prioritize remediation for internet-facing upload services, automated file ingestion systems, email/document gateways, and any service that processes untrusted TIFF files without user review.
• Apply vendor updates for libtiff as soon as fixed packages are available; rebuild containers and redeploy images that inherit vulnerable libtiff versions.
• Temporarily restrict TIFF uploads or route TIFF files through sandboxed detonation/validation for workflows that cannot be patched quickly.
• Ensure image-processing services run as non-privileged users with filesystem, network, and process isolation.
• Monitor crash logs, core dumps, and EDR telemetry for repeated failures in applications using libtiff, especially after processing externally supplied TIFF files.
• Search for suspicious TIFF files recently received through email, uploaded to applications, or introduced into shared processing directories around the time of crashes.
• Retain potentially malicious samples, crash dumps, and relevant logs for forensic analysis, but handle files in an isolated malware-analysis environment.