CVE-2026-106110

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 2.0.0 through 4.1.2, decoding an attacker-supplied 32-bit floating-point TIFF as Image<HalfVector4> and applying HistogramEqualization can produce a non-finite or out-of-range luminance in ColorNumerics.GetBT709Luminance. GrayscaleLevelsRowOperation.Invoke uses the resulting value as an unchecked histogram offset, causing an unsafe out-of-range access and process termination. Adaptive Histogram Equalization and AutoLevel are not affected. The issue is fixed in version 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.