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

CVE-2026-106118 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. When decoding tiled TIFF files with fax compression (T4/T6/Modified Huffman), the tile destination buffer is allocated using TileWidth, but the fax decompressor is constructed using the full frame.Width (ImageWidth), causing scanlines of full image width to be written into a tile-width-sized buffer. This size mismatch results in attacker-controlled out-of-bounds writes, heap corruption, and deterministic process termination. The vulnerability was reported by the Kimi Security Team and published on August 20, 2026, with a CVSS v3.1 base score of 7.5 (High) (Github Advisory, GitHub Security Advisory).

The root cause (CWE-787: Out-of-bounds Write) lies in TiffDecompressorsFactory.Create, which ignores the isTiled, tileWidth, and tileHeight parameters when constructing T4, T6, and Modified Huffman decompressors, always passing the full frame.Width instead of tileWidth. As a result, TiffDecoderCore.DecodeTilesChunky allocates tile buffers sized as ceil(TileWidth * bpp / 8) * TileLength bytes, but the decompressor writes frame.Width bits per row via BitWriterUtils.WriteBits with no bounds check against the tile buffer. With a crafted TIFF using ImageWidth=4,000,000 and TileWidth=16, this writes approximately 2 MB past a 32-byte buffer per tile, triggering a System.AccessViolationException and process abort. The attack surface is any call to Image.Load(stream) on an attacker-supplied tiled TIFF with Compression=3 (T4) or T6; no overlong run codes are required — perfectly legal per-row run codes suffice. A PoC crafted file (~9.8 KB) was included in the advisory (GitHub Security Advisory, Fix Commit).

Successful exploitation causes a deterministic process crash (Denial of Service) in any application that decodes untrusted tiled TIFF images using SixLabors.ImageSharp versions 3.0.0–4.1.0. Beyond availability impact, the heap out-of-bounds write is attacker-tunable in both per-tile length and row width, representing a potential code execution surface depending on heap layout and platform mitigations. There is no confidentiality or integrity impact assessed in the CVSS scoring, but the heap corruption window (demonstrated silently advancing >512 MB of bit offset in T6 all-white variants) could be leveraged for further exploitation in certain environments (Github Advisory, GitHub Security Advisory).

No public proof-of-concept exploit code has been released beyond the PoC TIFF file shared privately with the vendor during coordinated disclosure. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.603% (47th percentile), indicating a relatively low near-term exploitation probability. The vulnerability is automatable and requires no authentication, privileges, or user interaction, making it trivially exploitable by any attacker who can supply a malicious TIFF file to an affected service (Github Advisory, Feedly).

1. Craft a malicious tiled TIFF file: Create a TIFF with a standard tiled header specifying a very large ImageWidth (e.g., 4,000,000), a small TileWidth (e.g., 16), TileLength=16, and Compression=3 (T4) or Compression=4 (T6). Include valid per-row fax run codes (e.g., 400 makeup codes + EOL per row) — no overlong runs are needed.
2. Deliver the file to the target: Upload or submit the crafted TIFF to any service or application that processes user-supplied images using SixLabors.ImageSharp (e.g., an image upload endpoint, a document converter, or a thumbnail generator).
3. Trigger decoding: The application calls Image.Load(stream) or equivalent, which invokes TiffDecoderCore.DecodeImageWithTiles → DecodeTilesChunky. The decompressor is constructed with frame.Width (4,000,000) but writes into a tile buffer sized for TileWidth=16 (32 bytes).
4. Heap OOB write occurs: The T4/T6 decompressor writes approximately ImageWidth/8 * TileLength bytes (~2 MB) past the 32-byte tile buffer, corrupting heap memory.
5. Process crash (DoS): The application terminates with System.AccessViolationException: Attempted to read or write protected memory and exits with code 134 (core dumped), achieving denial of service (GitHub Security Advisory).

• Logs: Application crash logs or event logs showing System.AccessViolationException: Attempted to read or write protected memory with a stack trace referencing SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits, T4TiffCompression.WritePixelRun, or T4TiffCompression.Decompress.
• Process: Unexpected process termination (exit code 134 / SIGABRT) of the .NET application hosting ImageSharp, particularly following receipt of a TIFF file upload or processing request.
• File System: Presence of crafted TIFF files with unusually large ImageWidth values (e.g., millions of pixels) combined with very small TileWidth values (e.g., 16) and fax compression types (Compression tag = 3 or 4) in upload directories or temporary processing folders.
• Network: Repeated HTTP requests submitting TIFF files to image processing endpoints, especially from a single source IP, followed by service unavailability or 5xx error responses indicating process crashes (GitHub Security Advisory).

Upgrade SixLabors.ImageSharp to version 4.1.1 or later, which fixes the vulnerability by passing tileWidth (instead of frame.Width) to T4, T6, and Modified Huffman decompressors when processing tiled TIFFs, and adds explicit bounds checks to prevent decoded runs from exceeding the row width (v4.1.1 Release, Fix PR). As a short-term workaround where upgrading is not immediately possible, implement input validation to reject TIFF files where TileWidth is significantly smaller than ImageWidth, or where fax compression is used with tiled layout. Additionally, consider sandboxing image processing operations in a separate process to limit the blast radius of process crashes caused by malicious inputs.

The vulnerability was reported by the Kimi Security Team (bug-report@moonshot.ai) under coordinated disclosure, and the SixLabors maintainer (JimBobSquarePants) responded promptly, merging the fix on August 20, 2026 — the same day the advisory was published (Github Advisory, Fix PR). The fix was rapidly adopted across the ecosystem, with numerous dependent projects (including Microsoft's ONNX Runtime) issuing dependency bumps to 4.1.1 or later within days of the release.