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

CVE-2026-106114 is a memory allocation vulnerability in SixLabors ImageSharp, a .NET 2D graphics library, where ICC CLUT (Color Lookup Table) parsing allocates memory based on attacker-controlled channel and grid dimensions without first validating that the declared data is actually present in the profile. The flaw affects all versions from 1.0.0-beta0001 through 4.1.1 (inclusive) and was disclosed via a GitHub Security Advisory published September 15, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is CWE-789 (Memory Allocation with Excessive Size Value): IccDataReader.ReadClutF32 computes the allocation size as the product of attacker-declared input channel count and grid points per channel (e.g., 3^15 × 15 = 215,233,605 floats, ~861 MB) before reading or verifying any CLUT payload data. In v1–v3, the same defect exists in the public lazy IccProfile.Entries accessor via a jagged array representation (~115 MB allocation). In v4.0.0–v4.1.1, the vulnerable path is reached automatically during Image.Load when DecoderOptions.ColorProfileHandling is set to ColorProfileHandling.Convert; the default Preserve mode does not trigger the conversion pipeline. The fix, introduced in commit 8de892a, adds a GetClutLength helper that validates the computed byte count against remaining stream data before any allocation is attempted (GitHub Advisory, Fix Commit).

Successful exploitation causes the target application to transiently allocate approximately 861 MB of managed memory per malicious request, resulting in significant memory pressure and potential denial of service under resource-constrained environments. There is no impact on confidentiality or data integrity — the allocation failure is caught as an InvalidIccProfileException and the process continues normally, but repeated requests could exhaust available memory and degrade or halt service availability. The vulnerability has no lateral movement potential and does not enable code execution or privilege escalation (GitHub Advisory).

A complete, runnable proof-of-concept (PoC) in C# with a Docker setup is publicly available via the GitHub Security Advisory, demonstrating the 861 MB allocation bug against ImageSharp 4.1.1 (GitHub Advisory). The vulnerability is network-exploitable with no authentication or user interaction required, and NVD SSVC classifies it as automatable. The EPSS score is approximately 0.37%, and no active in-the-wild exploitation has been reported. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Craft a malformed ICC profile: Construct a ~200-byte ICC v4 RGB profile containing an A2B0 multi-process-elements (mpet) tag with a CLUT element that declares 15 input channels, 15 output channels, and 3 grid points per channel. Truncate the profile immediately after the CLUT grid descriptor, omitting all actual CLUT float values.
2. Embed the profile in a PNG image: Create a 1×1 pixel PNG image and embed the malformed ICC profile in its iCCP chunk using a standard PNG encoder (e.g., ImageSharp's PngEncoder).
3. Deliver the image to the target: Upload or submit the crafted PNG to any endpoint that processes images using SixLabors.ImageSharp with DecoderOptions.ColorProfileHandling = ColorProfileHandling.Convert (required for v4.x; for v1–v3, simply accessing IccProfile.Entries on a decoded image triggers the path).
4. Trigger oversized allocation: When Image.Load processes the image, IccDataReader.ReadClutF32 computes 3^15 × 15 = 215,233,605 floats (~861 MB) from the untrusted dimensions and attempts the allocation before detecting the truncated payload.
5. Observe denial-of-service effect: The allocation causes severe memory pressure; an InvalidIccProfileException is eventually thrown and caught, but the ~861 MB transient allocation may cause OOM conditions or service degradation under repeated requests (GitHub Advisory).

• Network: Repeated HTTP requests submitting small image files (e.g., ~200-byte PNG payloads with embedded ICC profiles) to image-processing endpoints; unusual upload patterns with minimal image dimensions (e.g., 1×1 pixels).
• Logs: Application logs showing repeated SixLabors.ImageSharp.Metadata.Profiles.Icc.InvalidIccProfileException: Invalid conversion method or Invalid CLUT dimensions exceptions correlated with image decode operations.
• Process/Memory: Sudden spikes in managed heap allocation (approaching or exceeding 861 MB per request) visible in .NET runtime metrics or APM tools; GC pressure events or OOM exceptions in application event logs.
• File System: Presence of crafted PNG files with anomalously small file sizes but embedded iCCP chunks containing truncated ICC profiles (GitHub Advisory).

Upgrade SixLabors.ImageSharp to version 4.1.2 or later, which validates CLUT storage size against available data before allocation (v4.1.2 Release). For applications on v4.x that cannot immediately upgrade, ensure DecoderOptions.ColorProfileHandling is set to ColorProfileHandling.Preserve (the default), which bypasses the vulnerable ICC conversion path entirely. Additionally, implement upstream input validation (e.g., file size limits, image dimension checks) and memory allocation limits on image-processing operations to reduce exposure. Note that v1–v3 users are also affected via the IccProfile.Entries accessor and should upgrade to v4.1.2 (GitHub Advisory, Fix PR).

The vulnerability was reported by security researcher MegaManSec and addressed by SixLabors maintainer JimBobSquarePants, who merged a comprehensive hardening PR (#3187) covering multiple codec and metadata input validation issues beyond just the ICC CLUT flaw (Fix PR). The advisory notes that no active exploitation is known and characterizes the impact as memory pressure rather than process termination, reflecting a measured severity assessment. Community response is visible through numerous downstream dependency bump PRs across open-source projects following the v4.1.2 release.