Description

ImageSharp is a 2D graphics library. From 3.0.0 until 4.1.1, tiled TIFF decoding allocates a destination buffer using TileWidth but TiffDecompressorsFactory.Create constructs T4, T6, and Modified Huffman decompressors using the full frame width. TiffDecoderCore.DecodeTilesChunky can therefore direct frame-width fax scanlines into a tile-width buffer when TileWidth is smaller than ImageWidth. The mismatch causes attacker-controlled out-of-bounds writes, heap corruption, and process termination even with legal per-row run codes. This tiled-path vulnerability is distinct from oversized CCITT runs in strip decoding. This issue is fixed in version 4.1.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-06T19:17:42.640Z",
  "pubdate": "2026-10-06T19:17:42.640Z",
  "executiveSummary": "ImageSharp versions 3.0.0 through 4.1.0 contain a critical heap-based buffer overflow vulnerability within the tiled TIFF decoding module.\nThe vulnerability arises from a mismatch between the allocated destination buffer size (based on TileWidth) and the operational capacity of the decompressors (based on full ImageWidth).\nAn attacker can leverage this discrepancy by supplying a crafted TIFF image with a TileWidth smaller than the actual ImageWidth, forcing the TiffDecoderCore.DecodeTilesChunky function to perform out-of-bounds memory writes.\nThe impact of successful exploitation includes heap corruption, arbitrary code execution, or process termination (Denial of Service).\nThis flaw is specific to the tiled decoding path and remains distinct from previously identified CCITT strip decoding issues.\nNo authentication is required to trigger this vulnerability, as it manifests during the routine image parsing process.",
  "technicalDetails": "The vulnerability resides in the interaction between TiffDecompressorsFactory.Create and TiffDecoderCore.DecodeTilesChunky within the ImageSharp graphics library. During the initialization of tiled TIFF decoding, the library allocates a destination buffer sized according to the tile dimensions defined in the TIFF metadata (specifically TileWidth).\nHowever, the decompressors instantiated by TiffDecompressorsFactory.Create—specifically those handling T4, T6, and Modified Huffman compression formats—are configured to process data based on the full frame width (ImageWidth) rather than the TileWidth. This discrepancy introduces a logic flaw where the decompressor assumes a larger destination buffer capacity than what has been allocated for the tiled path.\nThe exploitation flow proceeds as follows: An attacker crafts a malicious TIFF file where the metadata specifies a TileWidth significantly smaller than the total ImageWidth. When ImageSharp processes this file, the TiffDecoderCore.DecodeTilesChunky function initiates the decoding of fax scanlines. Because the underlying decompressors operate on the ImageWidth, they produce scanline data exceeding the boundaries of the tile-specific buffer. The system then writes this overflow data into adjacent heap memory, bypassing the allocated buffer constraints.\nThis process results in an out-of-bounds (OOB) write. Even if the per-row run codes are technically valid according to the compression protocol, the structural mismatch ensures that the output data spills over into unauthorized segments of the heap. Given that this occurs within a memory-managed environment, the corruption can lead to the overwrite of object metadata or functional pointers, potentially facilitating arbitrary code execution if the heap layout can be reliably manipulated.\nThis vulnerability is restricted to the tiled decoding path, making it architecturally distinct from OOB vulnerabilities found in CCITT strip decoding. The issue affects all versions from 3.0.0 up to, but not including, 4.1.1. No authentication is necessary, as the vulnerability is triggered automatically upon the library attempting to parse a maliciously crafted image file."
}