CVE-2026-106116 in ImageSharp
Summary
by MITRE • 10/06/2026
ImageSharp is a 2D graphics library. From 2.0.0 until 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, ExifReader.ReadValue64 returns without advancing the stream or terminating the outer loop, so a small malformed BigTIFF can keep one decoder thread executing for an attacker-controlled duration. This report does not claim worker-pool exhaustion. This issue is fixed in version 4.1.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within ImageSharp versions ranging from 2.0.0 to 4.1.2 represents a significant logic error in the handling of BigTIFF metadata, specifically affecting the ExifReader component when processing 64-bit image formats. This library is widely used for high-performance graphics manipulation and decoding across various .NET applications. The core issue stems from an incorrect assumption regarding stream integrity during the parsing of Image File Directory entries. When the parser encounters a malformed BigTIFF file where fewer than twenty bytes remain in the input stream, it fails to properly validate whether sufficient data exists to read a complete 64-bit value or entry structure. Instead of terminating the loop and raising an exception indicative of truncated data, the ExifReader.ReadValue64 method returns without advancing the internal stream pointer or breaking out of the outer iteration loop that processes IFD entries.
This specific logic flaw creates a condition where the decoder thread enters an infinite execution state rather than failing gracefully. Because the stream position does not advance and the termination condition is never met, the application continues to cycle through this faulty code path indefinitely. While the report explicitly notes that this issue should not be conflated with worker-pool exhaustion attacks in terms of resource consumption volume, the operational impact remains severe for any service relying on synchronous or thread-bound image processing pipelines. An attacker who can supply a crafted BigTIFF file containing minimal but malformed metadata entries can force a dedicated decoder thread to execute indefinitely. This effectively results in a denial-of-service condition by consuming CPU cycles and blocking that specific worker thread from handling other requests, thereby degrading the availability of the application hosting ImageSharp.
From a classification perspective, this vulnerability aligns with CWE-835, which describes loops that do not terminate correctly due to improper loop control logic or missing exit conditions. It also relates closely to CWE-20, Improper Input Validation, as the parser fails to verify that sufficient data is present before attempting to read structured entries from a potentially truncated stream. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior facilitates resource exhaustion attacks against application services, particularly in web contexts where image uploads are processed asynchronously or synchronously by limited thread pools. The lack of bounds checking on the remaining byte count allows for an attacker-controlled duration of execution, turning a simple parsing error into a persistent availability threat.
The recommended mitigation is to upgrade ImageSharp immediately to version 4.1.2 or later, where this logic has been corrected to properly detect insufficient data and terminate processing with an appropriate exception rather than looping infinitely. For organizations unable to patch instantly due to dependency constraints, implementing strict input validation at the ingestion layer can provide a temporary defense-in-depth measure. This includes limiting the size of uploaded metadata blocks, enforcing maximum file sizes for TIFF images, or utilizing sandboxed environments where image decoding occurs in isolated processes with resource limits such as CPU time quotas and memory caps. These controls ensure that even if a malformed file triggers this logic error, the impact is contained within defined boundaries rather than affecting the stability of the main application thread pool.