CVE-2026-106112 in ImageSharp
Summary
by MITRE • 10/06/2026
ImageSharp is a 2D graphics library. From 4.0.0 until 4.1.2, ICC LUT16 conversion accepts more than four output channels even though ClutCalculator.Calculate and LutEntryCalculator.CalculateLut store intermediate and output values in Vector4. When DecoderOptions.ColorProfileHandling is set to Convert, a malformed embedded profile can direct interpolation and output-LUT operations to write one float per declared channel beyond the four-float destination. This can corrupt memory and terminate the process; the default Preserve mode does not run ICC conversion. 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
ImageSharp, a widely used open-source library for handling 2D graphics operations such as image decoding, encoding, and manipulation, contains a critical memory corruption vulnerability within its International Color Consortium profile processing logic. The flaw exists specifically in versions ranging from 4.0.0 through 4.1.2 and affects the ICC LUT16 conversion mechanism. This component is responsible for translating color profiles to ensure consistent color representation across different devices and formats, a standard process defined by industry norms such as those managed by the International Color Consortium itself. The vulnerability arises from a mismatch between the declared number of output channels in an embedded ICC profile and the fixed-size data structures used internally by the library to store intermediate calculations and final results.
The technical root cause lies in how the ClutCalculator.Calculate method and LutEntryCalculator.CalculateLut method handle vector operations. These internal functions are designed to work with Vector4 objects, which inherently support exactly four components or channels, typically corresponding to Red, Green, Blue, and Alpha values in standard image processing workflows. However, when an attacker provides a malformed ICC profile that declares more than four output channels, the library fails to validate this count against its internal buffer constraints before proceeding with interpolation and lookup table operations. Consequently, during the execution of these color conversion routines, the code attempts to write one float value for each declared channel beyond the initial four into memory locations adjacent to the intended Vector4 destination array.
This out-of-bounds write operation results in heap-based buffer overflow or stack corruption, depending on where the intermediate calculations are allocated within the application's runtime environment. The immediate operational impact is severe instability and potential remote code execution capabilities for an attacker who can force a victim system to process maliciously crafted image files containing these malformed profiles. When DecoderOptions.ColorProfileHandling is configured to Convert mode, which triggers this specific conversion path, the memory corruption occurs reliably upon processing the affected profile data. This leads to immediate termination of the host application due to access violations or undefined behavior that may allow an attacker to overwrite critical control flow data such as return addresses or function pointers. It is important to note that the default setting for ColorProfileHandling in ImageSharp is Preserve, which bypasses this conversion logic entirely and thus does not expose users to this specific vulnerability unless they have explicitly opted into aggressive color profile transformation features.
From a classification perspective, this issue aligns with CWE-120 Buffer Copy without Checking Size of Input Classic buffer overflow vulnerabilities, specifically manifesting as an out-of-bounds write that compromises memory integrity. In the context of attack tactics and techniques, this vulnerability facilitates exploitation vectors associated with ATT&CK technique T1203 Exploitation for Client Execution if the processed image is part of a phishing campaign or malicious document delivery mechanism where triggering automatic rendering leads to code execution on the client machine. The lack of input validation regarding channel counts represents a failure in boundary enforcement, allowing external data to dictate memory layout operations beyond safe limits.
Mitigation strategies primarily involve upgrading to version 4.1.2 or later, where this logic has been corrected to properly validate channel counts and prevent writes exceeding the allocated Vector4 boundaries. For environments that cannot immediately upgrade, administrators should ensure that DecoderOptions.ColorProfileHandling remains set to its default Preserve mode rather than Convert when processing untrusted image inputs. Additionally, implementing strict input validation at the application layer before passing images to ImageSharp can provide an additional defense-in-depth measure by rejecting any ICC profiles with channel counts exceeding standard RGB or RGBA limits of four channels. Security teams should also monitor for anomalous process terminations in applications utilizing this library version range as a potential indicator of exploitation attempts targeting this memory corruption flaw.