SixLabors.ImageSharp is vulnerable to Out-of-bounds Write in versions 3.0.0 - 4.1.0 #156

Activity

1. timgilmore commented on Sep 10, 2026

   

   timgilmore

   on Sep 10, 2026

   More actions

   Aikido also flagged this for us on 8/25/26. We need this to be resolved to satisfy security requirements.
2. sydseter commented on Sep 30, 2026

   

   sydseter

   on Sep 30, 2026

   Last edited by sydseter

   Author

   More actions

   The vulnerable decoder is exploitable as far as I can see.

   • Single-frame TIFF loading calls Image.Load(Binary) (AnyBitmap.cs:2876).
   • RotateFlip and Redact directly call ImageSharp (AnyBitmap.cs:1486).
   • CreateMultiFrameTiff(IEnumerable) directly loads input paths through ImageSharp (AnyBitmap.cs:1224).
   • The normal multi-page TIFF path uses BitMiracle.LibTiff.NET, so that does not reach these ImageSharp bugs. However, the rest of the calls bypass that protection.

   The netstandard2.0 build uses ImageSharp 2.1.13 (IronSoftware.Drawing.Common.csproj:43). This is outside the affected range.

   To fix this, you need to upgrade the net60 ImageSharp dependency to 4.1.1 or later, and update the matching ImageSharp.Drawing dependency and the manually maintained versions in IronSoftware.Drawing.nuspec.
3. dany-ironsoftware commented on Oct 8, 2026

   

   dany-ironsoftware

   on Oct 8, 2026

   More actions

   Hi @sydseter,

   Thanks for the report.

   This issue has already been logged with our development team and is currently under discussion. We're treating it as a high priority, and I'll get back to you as soon as it's resolved.

   👍React with 👍2Reacted by Greg Smulko and AudunK
4. garyrknutson commented on Oct 17, 2026

   

   garyrknutson

   on Oct 17, 2026

   More actions

   Adding a related ask, since this ticket is already tied to Jira ticket DW-38 — your internal ticket (referenced in PR #158) for adding a .NET 8 target with the patched ImageSharp 4.1.2.

   We're tracking a Snyk finding against SixLabors.ImageSharp on our side (CVE range [2.1.0,4.1.2) / [1.0.0-beta0001,4.1.2) — Out-of-bounds Write, Memory Allocation with Excessive Size, Infinite Loop), which affects the netstandard2.0 build of IronSoftware.System.Drawing pinned to ImageSharp 2.1.13, since we're on .NET Framework and can't move to the .NET 8 target that PR #158 fixes.

   @sydseter's comment above confirms the netstandard2.0 build is on 2.1.13 and currently out of scope for this fix. Separately, issue #131 (closed in <24h) shows a precedent where a netstandard2.0-targeting ImageSharp bump (2.1.9 → 2.1.10) was shipped alongside the net60 fix for a different CVE.

   Is a similar backport possible here — bumping the netstandard2.0 target to whatever current Apache-licensed SixLabors.ImageSharp 2.1.x release addresses these CVEs (if one exists), separate from the .NET 8/ImageSharp 4.x work in PR #158?

   That would let .NET Framework consumers like us close this out without needing a framework migration.

   Happy to open a separate issue if that's cleaner for tracking.
5. dany-ironsoftware commented on Oct 21, 2026

   

   dany-ironsoftware

   on Oct 21, 2026

   More actions

   Hi @garyrknutson, thanks for the detailed follow-up, and for pointing to #131.

   About the backport: we'd normally do what we did in #131 and bump the netstandard2.0 target to a patched 2.1.x release. This time Six Labors hasn't released a 2.x version that fixes these CVEs, so there's nothing to bump to. Instead, we've blocked the vulnerable paths inside our own library.

   What we changed for netstandard2.0 / .NET Framework

   IronSoftware.System.Drawing 2026.11.4 adds an image check to the netstandard2.0 build. It runs before ImageSharp decodes anything and covers every path @sydseter listed:

   • single-frame TIFF loading (FromBytes / FromStream / FromFile / constructors)
   • RotateFlip and Redact
   • CreateMultiFrameTiff / CreateMultiFrameGif
   • the internal ImageSharp casts

   We also added a public IronSoftware.Drawing.ImageSharpLoader.Load(...). It's a drop-in replacement for Image.Load(...) for code that calls ImageSharp directly.

   Status of each advisory on .NET Framework (ImageSharp 2.1.13)

   Advisory	Issue	Status with System.Drawing 2026.11.4
   CVE-2026-106116	Infinite loop (malformed BigTIFF)	Blocked by the new check. We reproduced the hang on 2.1.13, and the file is now rejected immediately.
   CVE-2026-106110 / CVE-2026-106115	Out-of-bounds write in the CCITT T4/T6 TIFF encoders	Not reachable. System.Drawing writes TIFF through LibTiff and never uses ImageSharp's encoder.
   CVE-2026-106113	HistogramEqualization out-of-bounds index	Not reachable. System.Drawing never calls it.
   CVE-2026-106114	ICC colour lookup table excessive allocation	Not reachable. ImageSharp 2.x only reads the ICC header when decoding. The vulnerable parser runs only if IccProfile.Entries is read, and System.Drawing never reads it.
   CVE-2026-106117 / CVE-2026-106118 (the CCITT decoder issue in the original report)	Out-of-bounds write when decoding	Not applicable to 2.x. These only affect ImageSharp 3.0.0 and later. On .NET 6/8 they're fixed by ImageSharp 3.2.0 / 4.1.3.

   What you'll still see

   Snyk, Aikido and NuGet Audit match on package version, so they will keep flagging SixLabors.ImageSharp 2.1.13 on .NET Framework. We can't change that until Six Labors ships a fixed 2.x release. You may want to record these findings as mitigated or not reachable in your scanner, with this comment as the reference.

   The check covers ImageSharp use inside our libraries. If your own code calls ImageSharp directly with untrusted files, we recommend that you:

   • use ImageSharpLoader.Load(...) instead of Image.Load(...)
   • avoid HistogramEqualization, the CCITT TiffEncoder compressions and IccProfile.Entries

   Summary

   We have handled every part of these advisories that System.Drawing can reach on .NET Framework:

   • The BigTIFF infinite loop is now blocked.
   • The encoder, histogram and ICC issues are in code the library never calls.
   • The CCITT decoder issue doesn't affect ImageSharp 2.x at all.

   Could you try upgrading to IronSoftware.System.Drawing 2026.11.4 and let us know whether it works for you?

   👍React with 👍1Reacted by Jim-Fry