CVE-2026-106113 in ImageSharp
Summary
by MITRE • 10/06/2026
ImageSharp is a 2D graphics library. From 2.0.0 until 4.1.2, decoding an attacker-supplied 32-bit floating-point TIFF as Image<HalfVector4> and applying HistogramEqualization can produce a non-finite or out-of-range luminance in ColorNumerics.GetBT709Luminance. GrayscaleLevelsRowOperation.Invoke uses the resulting value as an unchecked histogram offset, causing an unsafe out-of-range access and process termination. Adaptive Histogram Equalization and AutoLevel are not affected by this report. This issue is fixed in version 4.1.2.
Be aware that VulDB is the high quality source for 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 critical input validation failure that leads to process termination through an out-of-bounds memory access. ImageSharp, widely utilized as a high-performance 2D graphics library for .NET applications, processes various image formats including Tagged Image File Format or TIFF files. The specific attack vector involves the decoding of maliciously crafted 32-bit floating-point TIFF images when processed using the HalfVector4 color type. This particular configuration allows an attacker to supply pixel data that results in non-finite values, such as NaN (Not a Number) or Infinity, during the luminance calculation phase. The flaw resides specifically within the ColorNumerics.GetBT709Luminance method, which is responsible for converting RGB color components into grayscale luminance values based on the BT.709 standard used in high-definition video and imaging systems.
When a 32-bit floating-point TIFF image containing extreme or malformed pixel values is decoded as Image<HalfVector4>, the subsequent application of Histogram Equalization triggers the vulnerable code path. The GetBT709Luminance function fails to properly validate these non-finite inputs before proceeding with arithmetic operations. Consequently, it returns a luminance value that is either outside the expected numerical range or represents an undefined mathematical state. This invalid result is then passed directly to the GrayscaleLevelsRowOperation.Invoke method without any sanitization checks. The operation treats this erroneous luminance value as an offset for histogram calculations, leading to arithmetic underflow or overflow conditions when calculating array indices.
The operational impact of this flaw is a denial of service against applications utilizing ImageSharp. Because the invalid index derived from the non-finite luminance value causes an unsafe out-of-range access within internal data structures, the .NET runtime throws an unhandled exception that terminates the process. This behavior effectively allows any user who can upload or supply such a malformed TIFF file to crash the hosting application server or client-side processing pipeline. It is important to note that this specific vulnerability does not affect Adaptive Histogram Equalization or AutoLevel operations, indicating that the flaw is isolated to the standard histogram equalization logic when applied to grayscale conversions of floating-point images.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write in certain contexts where memory corruption might occur, though here it primarily manifests as an out-of-bounds read leading to exception handling failures. In the context of the MITRE ATT&CK framework, this vulnerability facilitates Availability Impact through exploitation of software vulnerabilities that lead to service disruption. The lack of boundary checks on numeric inputs is a common pattern in image processing libraries where performance optimization often bypasses rigorous validation steps for speed.
Mitigation strategies primarily involve upgrading ImageSharp to version 4.1.2 or later, which includes patches for this specific input handling defect. For environments unable to upgrade immediately, implementing strict file type restrictions and validating uploaded images before they are passed to the image processing pipeline can reduce exposure. Additionally, wrapping image decoding operations in try-catch blocks that handle arithmetic exceptions gracefully can prevent process termination, although this is a defensive coding practice rather than a root cause fix. Developers should also consider enforcing maximum dimensions and valid pixel value ranges during initial file ingestion stages to ensure that only well-formed data enters the core graphics processing logic.