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

CVE-2026-106116 is a Denial of Service vulnerability in SixLabors ImageSharp, a .NET 2D graphics library, caused by an unbounded loop in the BigTIFF IFD entry count parser. The ExifReader.ReadValues64 method trusts the 64-bit IFD entry count field without validating it against available stream data, allowing a malformed 24-byte BigTIFF file to keep a decoder thread in a non-progressing loop for an attacker-controlled duration. All versions from 2.0.0 through 4.1.1 of the SixLabors.ImageSharp NuGet package are affected; the issue is fixed in version 4.1.2. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is classified as CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop). In ExifReader.ReadValues64, the 64-bit IFD entry count field from a BigTIFF file is consumed directly without being bounded against the remaining bytes in the stream. When ReadValue64 is called to read a 20-byte IFD entry but fewer than 20 bytes remain, it returns without advancing the stream position and without signaling the outer loop to terminate. This creates a non-progressing loop that iterates billions of times on the same stream position. The fix, applied in commit 92b12d7, adds a pre-loop check that computes the maximum possible entry count from remaining stream bytes ((remainingDirectoryBytes - 8) / 20) and throws InvalidImageContentException if the declared count exceeds it (GitHub Advisory, Fix Commit).

Successful exploitation causes a single decoder thread to consume CPU resources for an attacker-controlled duration — demonstrated at over five seconds using a 24-byte input with an entry count of 5,000,000,000. The vulnerability has no confidentiality or integrity impact; the sole consequence is reduced availability of the image processing component. Applications that process untrusted image uploads without enforcing decoding timeouts are most at risk, as repeated submissions could progressively degrade service responsiveness (GitHub Advisory).

A public proof-of-concept (PoC) is available in the GitHub Security Advisory, including complete C# source code (Program.cs), a project file, and a Dockerfile that reproduces the >5-second hang with a 24-byte payload. The vulnerability is network-accessible, requires no authentication or user interaction, and is classified as automatable by NVD SSVC. The EPSS score is approximately 0.37%, and there is no evidence of active in-the-wild exploitation or CISA KEV catalog listing as of the advisory date (GitHub Advisory).

1. Craft the malicious payload: Construct a 24-byte little-endian BigTIFF file using the following structure: bytes 0–1 = 0x49 0x49 (little-endian marker), bytes 2–3 = 0x2B 0x00 (BigTIFF magic), bytes 4–5 = 0x08 0x00 (8-byte offset indicator), bytes 8–15 = 16 as a ulong (IFD offset), bytes 16–23 = an extremely large ulong entry count (e.g., 5000000000). No actual IFD entry data is included after the count field.
2. Deliver the payload: Submit the 24-byte file to any application endpoint that passes untrusted input to Image.Load() or a similar ImageSharp decoding method (e.g., an image upload API, avatar processor, or thumbnail generator).
3. Trigger the loop: ImageSharp's BigTIFF decoder reads the IFD offset, seeks to byte 16, reads the entry count (5,000,000,000), and begins iterating. Each call to ReadValue64 finds fewer than 20 bytes remaining, returns without advancing the stream, and the outer loop in ReadValues64 continues indefinitely.
4. Achieve denial of service: The decoder thread spins for an attacker-controlled duration (>5 seconds demonstrated). Repeated submissions can tie up multiple threads, degrading or blocking image processing for legitimate users (GitHub Advisory).

• Network: Repeated HTTP requests submitting very small image files (≤24 bytes) to image upload or processing endpoints; unusual volume of image decode requests from a single source IP.
• Application Logs: Elevated frequency of image decoding operations that do not complete within expected timeframes; absence of InvalidImageContentException responses for clearly malformed inputs on unpatched versions.
• Process/Performance: Sustained high CPU utilization on .NET worker threads handling image processing; thread pool starvation indicators in application performance monitoring (e.g., increased request queue depth, timeouts on unrelated requests).
• File System: Presence of anomalous 24-byte .tif or .tiff files in upload staging directories with valid BigTIFF headers but no IFD entry data (GitHub Advisory).

Upgrade SixLabors.ImageSharp to version 4.1.2 or later, which bounds the BigTIFF directory entry count against available stream bytes before entering the loop (v4.1.2 Release, Fix PR). Note that the fix is only available in the 4.x branch; users on 2.x or 3.x must upgrade to 4.1.2. If immediate upgrade is not feasible, implement application-level timeouts on all image decoding operations, enforce file size and type restrictions on uploaded images (e.g., reject files claiming to be TIFF/BigTIFF that are under a minimum viable size), and consider rate-limiting image processing endpoints.

The vulnerability was reported by security researcher MegaManSec and disclosed via the GitHub Security Advisory program on September 15, 2026. The SixLabors maintainer (JimBobSquarePants) addressed the issue as part of a broader codec hardening pull request (#3187) merged on September 12, 2026, which also fixed numerous other input validation issues across BMP, GIF, PNG, WebP, JPEG, ICC, EXR, and CCITT codecs. The fix was adopted rapidly by downstream projects, with multiple dependency-bump pull requests appearing across the ecosystem within weeks of the v4.1.2 release (GitHub Advisory, Fix PR).