Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-06T18:16:53.400Z",
  "pubdate": "2026-10-06T18:16:53.400Z",
  "executiveSummary": "ImageSharp versions 2.0.0 through 4.1.2 are susceptible to a Denial of Service (DoS) vulnerability originating from improper input validation within the BigTIFF processing logic.\nThe vulnerability is characterized by an infinite loop condition triggered during the parsing of malformed IFD (Image File Directory) entries in BigTIFF images.\nAn attacker can craft a specially malformed BigTIFF file that forces the decoder thread into an uninterruptible state by preventing stream progression.\nWhile this does not lead to complete worker-pool exhaustion, it allows an attacker to consume CPU cycles on the target server for an arbitrary, attacker-controlled duration.\nThis flaw impacts all applications utilizing the ImageSharp library for BigTIFF image processing, potentially leading to resource exhaustion or service degradation depending on the application's threading model and concurrency limits.\nNo authentication or specific privileges are required to trigger this vulnerability, as it is exploitable via processing untrusted image data.",
  "technicalDetails": "The vulnerability resides within the ExifReader.ReadValues64 function, which is responsible for parsing 64-bit BigTIFF image data. The core of the issue is a flaw in the input validation logic regarding IFD entry counts.\nWhen processing a BigTIFF image, the library trusts the declared entry count provided in the file headers. The function iterates once per declared entry, expecting the data stream to advance correctly during each iteration.\nThe vulnerability manifests when the underlying stream has fewer than 20 bytes remaining. In this state, the ExifReader.ReadValue64 method fails to correctly handle the boundary condition. Instead of throwing an exception, signaling an error, or terminating the processing loop, the function returns control to the caller without advancing the stream pointer.\nBecause the outer loop in ExifReader.ReadValues64 continues to execute, and the ReadValue64 function fails to progress the stream or signal that further processing is impossible, the decoder enters a state of infinite recursion or iteration.\nAttack Flow: 1. An attacker submits a malformed BigTIFF file containing an intentionally high IFD entry count relative to the actual file size. 2. The ExifReader.ReadValues64 function parses the metadata and begins iterating through the declared entries. 3. As the stream nears exhaustion (less than 20 bytes remaining), the internal call to ExifReader.ReadValue64 encounters the boundary condition. 4. The function returns without advancing the read position or updating the loop state. 5. The loop continues to re-evaluate the same state indefinitely, effectively hanging the specific decoder thread.\nThe exploitation does not require authentication or elevated privileges. It relies solely on the application's willingness to process an attacker-provided image file. The impact is a local CPU denial of service, where the thread remains occupied indefinitely, preventing the reclamation of resources and potentially impacting the responsiveness of the host application if the thread count is limited.\nThis behavior remains persistent across all versions from 2.0.0 through 4.1.2, at which point the library logic was corrected to ensure proper stream termination and loop exit conditions when insufficient data is provided."
}