CVE-2026-106117: 
C# vulnerability analysis and mitigation

CVE-2026-106117 is a heap out-of-bounds write vulnerability in SixLabors ImageSharp, a .NET 2D graphics library, affecting versions 3.0.0 through 4.1.0 (inclusive). When decoding strip-based TIFF images using CCITT Group 3 (T4) or Modified Huffman (Compression=2/3) compression, the CCITT decompressors pass attacker-controlled run lengths to BitWriterUtils.WriteBits without first validating them against the strip buffer boundary, enabling heap memory corruption and process termination. The vulnerability was discovered and reported by the Kimi Security Team, published to the GitHub Advisory Database on August 20, 2026, and assigned CVE-2026-106117 on October 6, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, SixLabors Advisory).

The root cause is an out-of-bounds write (CWE-787) in BitWriterUtils.WriteBits/WriteBit/WriteZeroBit, which use Unsafe.Add with read-modify-write semantics but never compare the write position against the target buffer length. Two independent code paths trigger the overflow: (a) in T4TiffCompression, rowsWritten only increments on EOL codes, so consecutive CCITT makeup codes accumulate unlimited run lengths in a single RunLength value that WritePixelRun then writes in one shot without bounds checking; (b) in ModifiedHuffmanTiffCompression.Decompress, the pixelsWritten > Width validation occurs at lines L90–L93 after the write at lines L56–L63, meaning the overflow completes before any exception is raised. The strip buffer is sized as ImageWidth × BitsPerSample/8 × RowsPerStrip (8 bytes in the PoC), and the attack surface is any call to Image.Load(stream) on an attacker-supplied strip TIFF via TiffDecoderCore.DecodeStripsChunky → TiffDecompressorsFactory.Create → Decompress — requiring no authentication or user interaction (SixLabors Advisory, Fix Commit).

Successful exploitation causes a fatal, uncatchable System.AccessViolationException that immediately terminates the host process (exit code 134, core dump), resulting in a reliable remote denial of service for any service that decodes untrusted TIFF images — including image hosting platforms, transcoding pipelines, thumbnail generators, and CMS backends. Beyond DoS, the heap OOB write has an attacker-controlled offset and length (~19.2 MB written past an 8-byte buffer), constituting a realistic heap-corruption primitive that could theoretically be leveraged for code execution, though no working RCE exploit has been demonstrated. There is no confidentiality or integrity impact confirmed at this time (SixLabors Advisory, GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub security advisory, including crafted TIFF files (poc-tiff-t4.tif and poc-tiff-mh.tif, ~90 KB each) and a reproduction driver (Program.cs) that deterministically crash the process (SixLabors Advisory). The vulnerability is fully automatable — no authentication, no privileges, and no user interaction are required, and the NVD SSVC assessment confirms automatable: yes. The EPSS score is approximately 0.425%, and there is no evidence of in-the-wild exploitation or CISA KEV catalog inclusion as of the advisory publication date (GitHub Advisory). No threat actor attribution has been reported.

1. Craft a malicious TIFF file: Create a strip-based TIFF with little-endian byte order (II, magic=42), ImageWidth=64, ImageLength=1, BitsPerSample=1, Photometric=WhiteIsZero, RowsPerStrip=1, and Compression=2 (Modified Huffman) or Compression=3 (T4 Group 3 1D). The strip buffer will be allocated as 8 bytes.
2. Populate strip data with oversized CCITT makeup codes: Encode the strip payload as: EOL (12-bit) + 60,000 × white makeup code 2560 (binary 000000011111, each representing 2,560 pixels) + white terminating code (000111). This declares a total run of approximately 153,600,001 pixels (~19.2 MB) into the 8-byte buffer.
3. Deliver the crafted TIFF to the target application: Supply the ~90 KB TIFF file as untrusted input via HTTP file upload, API endpoint, file system path, or any other channel that causes the application to call Image.Load() or an equivalent method on the file.
4. Application invokes the vulnerable decoder: Image.Load(stream) calls TiffDecoderCore.DecodeStripsChunky, which routes to TiffDecompressorsFactory.Create and then Decompress(). For Compression=2, ModifiedHuffmanTiffCompression.Decompress is invoked; for Compression=3, T4TiffCompression.
5. Decompressor writes past the strip buffer without bounds checking: For T4, consecutive makeup codes accumulate in RunLength without incrementing rowsWritten (which only increments on EOL), and WritePixelRun writes the full ~153M-pixel run via BitWriterUtils.WriteBits using Unsafe.Add without checking buffer bounds. For Modified Huffman, the write at lines L56–L63 occurs before the width validation at L90–L93.
6. Heap memory is corrupted: Approximately 19.2 MB of bits are written linearly past the 8-byte strip buffer, corrupting managed heap memory with attacker-controlled offset and length.
7. Process terminates with a fatal exception: The .NET runtime detects the memory violation and raises an uncatchable System.AccessViolationException, aborting the process with exit code 134 (core dumped) (SixLabors Advisory).

• Logs: Application crash logs or event logs showing Fatal error. System.AccessViolationException: Attempted to read or write protected memory with a stack trace referencing SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits, ModifiedHuffmanTiffCompression.Decompress, or T4TiffCompression.WritePixelRun, and TiffDecoderCore.DecodeStripsChunky.
• Process: Unexpected process termination (exit code 134) of the application hosting ImageSharp, particularly following receipt of a TIFF file; core dump files generated in the working directory of the .NET process.
• Network: Inbound HTTP requests delivering TIFF files (Content-Type: image/tiff) with unusually large strip data sections (~90 KB or more) relative to declared image dimensions (e.g., 64×1 pixels); repeated delivery of small-dimension TIFF files from the same source IP.
• File System: Presence of TIFF files with Compression tag value of 2 or 3, ImageWidth of 64 or similar small value, and strip data disproportionately large relative to image dimensions; core dump files (e.g., core.*) in the application directory (SixLabors Advisory).

The primary remediation is to upgrade SixLabors ImageSharp to version 4.1.1 or later, which adds explicit bounds checks in ModifiedHuffmanTiffCompression, T4TiffCompression, and T6TiffCompression that throw an ImageFormatException if a decoded run exceeds the image row width before any write occurs (v4.1.1 Release, Fix PR). If an immediate upgrade is not feasible, restrict TIFF file processing to trusted sources only and implement file type and metadata validation to reject TIFF images with Compression=2 or Compression=3 from untrusted users. Note that version 3.x does not appear to have received a backported fix, so upgrading to the 4.1.1+ branch is strongly recommended (GitHub Advisory).

The vulnerability was reported to SixLabors by the Kimi Security Team (bug-report@moonshot.ai) under coordinated disclosure, and the maintainer (JimBobSquarePants) merged the fix on the same day the advisory was published (August 20, 2026) (Fix PR). The fix was rapidly adopted across the ecosystem, with numerous dependent projects (including microsoft/onnxruntime, ppy/osu-framework, and others) opening automated dependency update PRs within days of the release (Fix PR). No significant independent researcher commentary or broad media coverage has been identified beyond the advisory itself.