CVE-2026-106113

In ImageSharp versions 3.0.0 through 4.1.1, tiled TIFF decoding allocates a destination buffer based on TileWidth while T4, T6, and Modified Huffman decompressors use the full frame width. When TileWidth is smaller than ImageWidth, frame-width fax scanlines are written into a tile-width buffer, causing out-of-bounds writes and heap corruption. The issue is fixed in version 4.1.1.

In ImageSharp versions 3.0.0 through 4.1.1, decoding a strip TIFF using CCITT Group 3 or Modified Huffman compression can pass attacker-expanded runs to BitWriterUtils.WriteBits without first checking the current row width. T4TiffCompression.WritePixelRun can accumulate oversized makeup-code runs, and ModifiedHuffmanTiffCompression.Decompress validates the width only after writing. The unchecked writes can overflow the strip buffer, corrupt heap memory, and terminate the process. The issue is fixed in version 4.1.1.

In ImageSharp from 2.0.0 to 4.1.2, ExifReader.ReadValues64 trusts the 64-bit BigTIFF IFD entry count and iterates once per declared entry. When fewer than 20 bytes remain, ReadValue64 returns without advancing the stream or terminating the loop, allowing a small malformed BigTIFF to keep a decoder thread executing for an attacker-controlled duration. Fixed in 4.1.2.

In ImageSharp versions 2.1.0 through 4.1.2, the TIFF CCITT Group 4 encoder allocates Width times rowsPerStrip bytes even though T6BitCompressor.CompressStrip can emit encoded row data and two 12-bit end-of-facsimile-block codes beyond that capacity. TiffCcittCompressor.WriteCode performs unchecked writes, and a decode-and-re-encode flow can inherit TiffCompression.CcittGroup4Fax and one-bit metadata from attacker-supplied input. The resulting out-of-bounds writes can corrupt memory and terminate the process. The issue is fixed in version 4.1.2.

In ImageSharp from 1.0.0-beta0001 to 4.1.2, ICC CLUT parsing calculates allocation sizes from attacker-declared dimensions before confirming the profile contains the declared values. IccDataReader.ReadClutF32 can request a large float array, and earlier parsing paths can allocate large jagged representations from a short truncated profile. In version 4, automatic conversion reaches the parser when ColorProfileHandling is Convert; default Preserve avoids that path. Fixed in 4.1.2.

In ImageSharp versions 4.0.0 through 4.1.2, ICC LUT16 conversion accepts more than four output channels even though ClutCalculator.Calculate and LutEntryCalculator.CalculateLut store intermediate and output values in Vector4. When DecoderOptions.ColorProfileHandling is set to Convert, a malformed embedded profile can direct interpolation and output-LUT operations to write one float per declared channel beyond the four-float destination. This can corrupt memory and terminate the process; the default Preserve mode does not run ICC conversion. The issue is fixed in version 4.1.2.

In ImageSharp from 4.0.0 to 4.1.2, ExrBaseDecompressor.UndoZipCompression accepts a nonempty ZIP or ZIPS inflate result shorter than the required EXR block size. ZipExrCompression.Decompress reconstructs the returned prefix while ExrDecoderCore processes the full expected block from a buffer obtained through Configuration.Default, allowing bytes from a completed prior ImageSharp operation to appear in decoded pixels. Applications exposing pixels or output from the later attacker-controlled EXR decode can disclose process-local image data. Fixed in 4.1.2.

In ImageSharp versions 2.0.0 through 4.1.2, the TIFF CCITT Group 3 encoder allocates an undersized compressed-data buffer for narrow 1-bit images. TiffCcittCompressor.Initialize does not reserve enough space for the row data and T4 end-of-line codes, and T4BitCompressor.CompressStrip reaches unchecked writes when TiffCompression.CcittGroup3Fax is selected directly or inherited from decoded TIFF metadata. An attacker-controlled encode or decode-and-re-encode flow can write beyond the logical output span, corrupt process memory, and terminate the process. The issue is fixed in version 4.1.2.