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.