Vulnerability-Lookup

GHSA-V76P-62QX-WWQ2

Vulnerability from github – Published: 2026-10-07 16:18 – Updated: 2026-10-07 16:18

Summary

ImageSharp: Tiled fax TIFF: tile buffer sized by TileWidth but fax decompressor writes scanlines of ImageWidth — heap OOB write

Details

Summary

When decoding a tiled TIFF with fax compression (T4/T6/MH), DecodeTilesChunky allocates each tile buffer from TileWidth (ceil(TileWidth*bpp/8)*TileLength bytes) but constructs the fax decompressor with frame.Width: TiffDecompressorsFactory ignores the isTiled/tileWidth/tileHeight parameters entirely. The T4/T6/MH decompressors treat the full image width as the scanline length and advance (and really write, via read-modify-write bit ops) frame.Width bits per row, with no bounds check against the tile buffer. The very first tile therefore writes linearly out of bounds — about ImageWidth/8 bytes per row × TileLength rows into a TileWidth-sized buffer. With ImageWidth=4,000,000, TileWidth=16, TileLength=16 this writes ~2 MB past a 32-byte buffer and kills the process deterministically; a T6 all-white variant advances the bit offset by >512 MB silently, showing an alarm-free heap-corruption window for the same defect. A crafted file fully controls the OOB length per tile and works with perfectly legal per-row run codes (no overlong runs needed).

Verified at commit 5cd4d0d26a82a9549f297a237aea9cf665bddff8 (main; latest release v4.1.0, the supported major).

Details

Root cause: a size mismatch between tile buffer allocation and decompressor width, because the factory drops the tile parameters.

Allocation: TiffDecoderCore.cs#L792-L794 — bytesPerTileRow = RoundUpToMultipleOfEight(tileWidth*bitsPerPixel); tile buffer = bytesPerTileRow*tileLength bytes (32 bytes in the PoC)
Mismatch: TiffDecoderCore.cs#L797 — CreateDecompressor<TPixel>(frame.Width, ..., isTiled: true, tileWidth, tileLength) passes the full frame width
Factory drops tile params: TiffDecompressorsFactory.cs#L56-L64 — T4/T6/MH decompressors receive only width (= frame.Width); isTiled/tileWidth/tileHeight ignored
OOB write sink: T4TiffCompression.cs#L69-L119, T6TiffCompression.cs#L76-L108 — per-row advance of this.width bits via BitWriterUtils.WriteBits with no buffer-length check (BitWriterUtils.cs#L51); note TiffDecoderCore.cs:829-831 later reads the buffer in bytesPerTileRow strides, confirming the protocol expects tile-width rows

Attack surface: Image.Load(stream) on an attacker-supplied tiled TIFF (TiffDecoderCore.DecodeImageWithTiles → DecodeTilesChunky). Default configuration; only requirement is a standard tiled TIFF header (TileWidth=16, TileLength=16) + Compression=3 (T4; T6 also constructible).

Suggested remediation: 1. Short-term: when isTiled, construct the T4/T6/MH decompressor with tileWidth (not frame width), or clip row writes to the caller-provided buffer length. 2. Root fix: bound the write side of BitWriterUtils (pass remaining bits), and validate every fax row advance against buffer capacity on both tiled and strip paths. 3. Regression tests: Compression=2/3/4 × tiled with TileWidth < ImageWidth, including a T6 black-pixel row (forces real WriteBit).

PoC

Full PoC posted as the first comment below: Program.cs (driver), poc-tiled-t4.tif (crafted file, ~9.8 KB, base64 inline), README.

Build a small console project referencing src/ImageSharp/ImageSharp.csproj and run it against the crafted file (or call Image.Load on it from any host).
Observed with ImageWidth=4,000,000, TileWidth=16, TileLength=16, T4 with 400 makeup codes + EOL per row:

tile payload 9642 bytes; rows write ~2,048,000 bytes into a 32-byte buffer Fatal error. System.AccessViolationException: Attempted to read or write protected memory. at SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits(Span`1<Byte>, IntPtr, IntPtr, Byte) at ...T4TiffCompression.WritePixelRun(...) at ...T4TiffCompression.Decompress(...) Aborted (core dumped); exit=134

Controls: the same file with Compression=None decodes normally (container is fine); a T6 all-white-rows variant advances >512 MB of bit offset without a real write (silent corruption window) before tripping on a directory-level TileOffsets count check.

Impact

What it is: out-of-bounds write (CWE-787). For any service decoding untrusted tiled TIFFs: remote, default-configuration, deterministic process crash (DoS), plus a heap OOB write whose per-tile length and row width are attacker-tunable — a potential code-execution surface. This is a vulnerability in the library itself, in scope of your SECURITY.md.
Who is impacted: applications decoding untrusted TIFF with SixLabors.ImageSharp at the current major (verified on main past v4.1.0); tiled + fax-compressed files are the trigger, which ordinary TIFF writers can produce.

Reported by Kimi Security Team (bug-report@moonshot.ai).

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "NuGet",
        "name": "ImageSharp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "4.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-106118"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-787"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-07T16:18:57Z",
    "nvd_published_at": "2026-10-06T19:17:42Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen decoding a tiled TIFF with fax compression (T4/T6/MH), `DecodeTilesChunky` allocates each tile buffer from **TileWidth** (`ceil(TileWidth*bpp/8)*TileLength` bytes) but constructs the fax decompressor with **frame.Width**: `TiffDecompressorsFactory` ignores the `isTiled/tileWidth/tileHeight` parameters entirely. The T4/T6/MH decompressors treat the full image width as the scanline length and advance (and really write, via read-modify-write bit ops) `frame.Width` bits per row, with no bounds check against the tile buffer. The very first tile therefore writes linearly out of bounds \u2014 about `ImageWidth/8` bytes per row \u00d7 TileLength rows into a `TileWidth`-sized buffer. With ImageWidth=4,000,000, TileWidth=16, TileLength=16 this writes ~2 MB past a 32-byte buffer and kills the process deterministically; a T6 all-white variant advances the bit offset by \u003e512 MB silently, showing an alarm-free heap-corruption window for the same defect. A crafted file fully controls the OOB length per tile and works with perfectly legal per-row run codes (no overlong runs needed).\n\nVerified at commit `5cd4d0d26a82a9549f297a237aea9cf665bddff8` (main; latest release v4.1.0, the supported major).\n\n## Details\n\nRoot cause: a size mismatch between tile buffer allocation and decompressor width, because the factory drops the tile parameters.\n\n- Allocation: [TiffDecoderCore.cs#L792-L794](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L792-L794) \u2014 `bytesPerTileRow = RoundUpToMultipleOfEight(tileWidth*bitsPerPixel)`; tile buffer = `bytesPerTileRow*tileLength` bytes (32 bytes in the PoC)\n- Mismatch: [TiffDecoderCore.cs#L797](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L797) \u2014 `CreateDecompressor\u003cTPixel\u003e(frame.Width, ..., isTiled: true, tileWidth, tileLength)` passes the full frame width\n- Factory drops tile params: [TiffDecompressorsFactory.cs#L56-L64](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/TiffDecompressorsFactory.cs#L56-L64) \u2014 T4/T6/MH decompressors receive only `width` (= frame.Width); `isTiled/tileWidth/tileHeight` ignored\n- OOB write sink: [T4TiffCompression.cs#L69-L119](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/Decompressors/T4TiffCompression.cs#L69-L119), `T6TiffCompression.cs#L76-L108` \u2014 per-row advance of `this.width` bits via `BitWriterUtils.WriteBits` with no buffer-length check ([BitWriterUtils.cs#L51](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/BitWriterUtils.cs#L51)); note `TiffDecoderCore.cs:829-831` later reads the buffer in `bytesPerTileRow` strides, confirming the protocol expects tile-width rows\n\nAttack surface: `Image.Load(stream)` on an attacker-supplied tiled TIFF (`TiffDecoderCore.DecodeImageWithTiles` \u2192 `DecodeTilesChunky`). Default configuration; only requirement is a standard tiled TIFF header (TileWidth=16, TileLength=16) + Compression=3 (T4; T6 also constructible).\n\n**Suggested remediation:**\n1. Short-term: when `isTiled`, construct the T4/T6/MH decompressor with `tileWidth` (not frame width), or clip row writes to the caller-provided buffer length.\n2. Root fix: bound the write side of `BitWriterUtils` (pass remaining bits), and validate every fax row advance against buffer capacity on both tiled and strip paths.\n3. Regression tests: Compression=2/3/4 \u00d7 tiled with TileWidth \u003c ImageWidth, including a T6 black-pixel row (forces real `WriteBit`).\n\n## PoC\n\nFull PoC posted as the first comment below: `Program.cs` (driver), `poc-tiled-t4.tif` (crafted file, ~9.8 KB, base64 inline), README.\n\n1. Build a small console project referencing `src/ImageSharp/ImageSharp.csproj` and run it against the crafted file (or call `Image.Load` on it from any host).\n2. Observed with ImageWidth=4,000,000, TileWidth=16, TileLength=16, T4 with 400 makeup codes + EOL per row:\n\n   ```\n   tile payload 9642 bytes; rows write ~2,048,000 bytes into a 32-byte buffer\n   Fatal error. System.AccessViolationException: Attempted to read or write protected memory.\n      at SixLabors.ImageSharp.Formats.Tiff.Compression.BitWriterUtils.WriteBits(Span`1\u003cByte\u003e, IntPtr, IntPtr, Byte)\n      at ...T4TiffCompression.WritePixelRun(...)\n      at ...T4TiffCompression.Decompress(...)\n   Aborted (core dumped); exit=134\n   ```\n\n3. Controls: the same file with Compression=None decodes normally (container is fine); a T6 all-white-rows variant advances \u003e512 MB of bit offset without a real write (silent corruption window) before tripping on a directory-level TileOffsets count check.\n\n## Impact\n\n- **What it is:** out-of-bounds write (CWE-787). For any service decoding untrusted tiled TIFFs: remote, default-configuration, deterministic process crash (DoS), plus a heap OOB write whose per-tile length and row width are attacker-tunable \u2014 a potential code-execution surface. This is a vulnerability in the library itself, in scope of your SECURITY.md.\n- **Who is impacted:** applications decoding untrusted TIFF with SixLabors.ImageSharp at the current major (verified on main past v4.1.0); tiled + fax-compressed files are the trigger, which ordinary TIFF writers can produce.\n\n---\n\n---\n\nReported by **Kimi Security Team** (bug-report@moonshot.ai).",
  "id": "GHSA-v76p-62qx-wwq2",
  "modified": "2026-10-07T16:18:57Z",
  "published": "2026-10-07T16:18:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-v76p-62qx-wwq2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106118"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/pull/3176"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/commit/9ee7d1dd5b62d8c9f16cc755e76828386bc2191f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SixLabors/ImageSharp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/SixLabors/ImageSharp/releases/tag/v4.1.1"
    }
  ],
  "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: Tiled fax TIFF: tile buffer sized by TileWidth but fax decompressor writes scanlines of ImageWidth \u2014 heap OOB write"
}

CVE-2026-106118 (GCVE-0-2026-106118)

Vulnerability from cvelistv5 – Published: 2026-10-06 17:59 – Updated: 2026-10-06 19:29

Title

ImageSharp: Tiled fax TIFF: tile buffer sized by TileWidth but fax decompressor writes scanlines of ImageWidth — heap OOB write

Summary

ImageSharp is a 2D graphics library. From 3.0.0 until 4.1.1, tiled TIFF decoding allocates a destination buffer using TileWidth but TiffDecompressorsFactory.Create constructs T4, T6, and Modified Huffman decompressors using the full frame width. TiffDecoderCore.DecodeTilesChunky can therefore direct frame-width fax scanlines into a tile-width buffer when TileWidth is smaller than ImageWidth. The mismatch causes attacker-controlled out-of-bounds writes, heap corruption, and process termination even with legal per-row run codes. This tiled-path vulnerability is distinct from oversized CCITT runs in strip decoding. This issue is fixed in version 4.1.1.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-06 19:27 UTC

CWE

CWE-787 - Out-of-bounds Write

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7580 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/SixLabors/ImageSharp/security/…	x_refsource_CONFIRM
https://github.com/SixLabors/ImageSharp/pull/3176	x_refsource_MISC
https://github.com/SixLabors/ImageSharp/commit/9e…	x_refsource_MISC
https://github.com/SixLabors/ImageSharp/releases/…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
SixLabors	ImageSharp	Affected: >= 3.0.0, < 4.1.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-106118",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-06T19:27:52.241408Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-06T19:29:39.226Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ImageSharp",
          "vendor": "SixLabors",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 3.0.0, \u003c 4.1.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "ImageSharp is a 2D graphics library. From 3.0.0 until 4.1.1, tiled TIFF decoding allocates a destination buffer using TileWidth but TiffDecompressorsFactory.Create constructs T4, T6, and Modified Huffman decompressors using the full frame width. TiffDecoderCore.DecodeTilesChunky can therefore direct frame-width fax scanlines into a tile-width buffer when TileWidth is smaller than ImageWidth. The mismatch causes attacker-controlled out-of-bounds writes, heap corruption, and process termination even with legal per-row run codes. This tiled-path vulnerability is distinct from oversized CCITT runs in strip decoding. This issue is fixed in version 4.1.1."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-787",
              "description": "CWE-787: Out-of-bounds Write",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-06T17:59:02.778Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-v76p-62qx-wwq2",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/SixLabors/ImageSharp/security/advisories/GHSA-v76p-62qx-wwq2"
        },
        {
          "name": "https://github.com/SixLabors/ImageSharp/pull/3176",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/SixLabors/ImageSharp/pull/3176"
        },
        {
          "name": "https://github.com/SixLabors/ImageSharp/commit/9ee7d1dd5b62d8c9f16cc755e76828386bc2191f",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/SixLabors/ImageSharp/commit/9ee7d1dd5b62d8c9f16cc755e76828386bc2191f"
        },
        {
          "name": "https://github.com/SixLabors/ImageSharp/releases/tag/v4.1.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/SixLabors/ImageSharp/releases/tag/v4.1.1"
        }
      ],
      "source": {
        "advisory": "GHSA-v76p-62qx-wwq2",
        "discovery": "UNKNOWN"
      },
      "title": "ImageSharp: Tiled fax TIFF: tile buffer sized by TileWidth but fax decompressor writes scanlines of ImageWidth \u2014 heap OOB write"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-106118",
    "datePublished": "2026-10-06T17:59:02.778Z",
    "dateReserved": "2026-10-06T15:33:55.333Z",
    "dateUpdated": "2026-10-06T19:29:39.226Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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 MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
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.

Action not permitted

GHSA-V76P-62QX-WWQ2

Summary

Details

PoC

Impact

CVE-2026-106118 (GCVE-0-2026-106118)

Tags

Sightings

Nomenclature

Related by attack behaviour