ZDF
Sign inSign up

Vulnerabilities

Security research · CVE-2026-106118

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

Published Oct 7, 2026 · catalog updated Oct 26, 2026 · ImageSharp: Tiled fax TIFF:

Last checked Oct 29, 2026. A connected source was read within the last 7 days.

Check if you run it

No confirmed exploitation is on record for CVE-2026-106118. EPSS is 0.60%. Act only if a listed version of ImageSharp: Tiled fax TIFF: is installed.

Gaps on this record

  • The stored product name is a package slug. The name on this page is taken from the title (ImageSharp: Tiled fax TIFF:).
  • No vendor fix or required action is stored. Compare the linked advisory before you change production.
Severity
High7.5
Known exploitation
Not in CISA/VulnCheck KEV
EPSS
0.60%
Remediation
Advisory link
Affected products
NuGet SixLabors.ImageSharp

## Summary When decoding a tiled TIFF with fax compression (T4/T6/MH), allocates each tile buffer from **TileWidth** ( bytes) but constructs the fax decompressor with **frame.Width**: ignores the 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) bits per row, with no bounds check against the tile buffer. The very first tile therefore writes linearly out of bounds — about bytes per row × TileLength rows into a -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 (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](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L792-L794) — ; tile buffer = bytes (32 bytes in the PoC) - Mismatch: [TiffDecoderCore.cs#L797](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/TiffDecoderCore.cs#L797) — passes the full frame width - Factory drops tile params: [TiffDecompressorsFactory.cs#L56-L64](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f297a237aea9cf665bddff8/src/ImageSharp/Formats/Tiff/Compression/TiffDecompressorsFactory.cs#L56-L64) — T4/T6/MH decompressors receive only (= frame.Width); ignored - OOB write sink: [T4TiffCompression.cs#L69-L119](https://github.com/SixLabors/ImageSharp/blob/5cd4d0d26a82a9549f29

Are you affected?

Enter the version you run. The result uses only the ranges stored on this record.

The check returns affected, not affected, or incomplete. It does not guess a version that is missing from the record.

  • NuGet SixLabors.ImageSharp3.0.0 → 3.2.0
  • NuGet SixLabors.ImageSharp4.0.0 → 4.1.1

How to fix CVE-2026-106118

What to do

Three questions, each answered from this record only. Confirm the vendor advisory before you patch.

Should you patch?

No confirmed exploitation is on record for CVE-2026-106118. EPSS is 0.60%. Act only if a listed version of ImageSharp: Tiled fax TIFF: is installed.

Which versions are affected?

Compare what you have installed with SixLabors.ImageSharp 3.0.0 → 3.2.0; SixLabors.ImageSharp 4.0.0 → 4.1.1. Compare the installed version with the linked vendor advisory before you change production.

What should an analyst verify?

CWE-787: Out-of-bounds Write. EPSS 0.60%. There is no CISA KEV listing. No Exploit-DB or Metasploit reference is linked. Use the source links for the original advisory.

Code

The project this record applies to. Exploit listings stay in References.

Timeline

Detection, updates, and resolution for this record.

  1. Oct 7, 2026 · GitHub Advisory Database

    Detected

    ## Summary When decoding a tiled TIFF with fax compression (T4/T6/MH), allocates each tile buffer from **TileWidth** ( bytes) but constructs the fax decompressor with **frame.Width**: ignores the 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) bits per row, with no bounds check against t

  2. Oct 26, 2026 · GitHub Advisory Database

    Fix available

    SixLabors.ImageSharp fixed in 3.2.0; SixLabors.ImageSharp fixed in 4.1.1

  3. Oct 26, 2026 · GitHub Advisory Database

    Fix available

    SixLabors.ImageSharp fixed in 3.2.0

  4. Oct 26, 2026 · GitHub Advisory Database

    Fix available

    SixLabors.ImageSharp fixed in 4.1.1

  5. Oct 26, 2026 · GitHub Advisory Database

    Updated

    ## Summary When decoding a tiled TIFF with fax compression (T4/T6/MH), allocates each tile buffer from **TileWidth** ( bytes) but constructs the fax decompressor with **frame.Width**: ignores the 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) bits per row, with no bounds check against t

Sources

References

Freshness

Last verified in this catalog Oct 26, 2026. Significant claims (KEV, EPSS, CVSS, affected ranges) come from the source rows above — open the original publisher for the authoritative advisory.

  • GitHub Advisory DatabaseOct 29, 2026
  • OpenSSF OSV / OSV ScannerOct 29, 2026
  • CVE.orgOct 27, 2026