Repository navigation
SixLabors.ImageSharp is vulnerable to Out-of-bounds Write in versions 3.0.0 - 4.1.0 #156
Description
Our Aikido Pipeline are reporting the following error:
https://intel.aikido.dev/cve/AIKIDO-2026-983562
https://intel.aikido.dev/cve/AIKIDO-2026-827156
Who does this affect?
You are affected if you use a version within the vulnerable range and decode untrusted TIFF images that use CCITT/fax (Group 3 or Modified Huffman) compression.
Background info
SixLabors.ImageSharp is vulnerable to an out-of-bounds write in versions 3.0.0-4.1.0.
How to fix this
Upgrade the SixLabors.ImageSharp library to the patched version.
Reacted by Tim Gilmore and Josh Crang
Activity
timgilmore commentedon Sep 10, 2026
Aikido also flagged this for us on 8/25/26. We need this to be resolved to satisfy security requirements.
sydseter commentedon Sep 30, 2026
The vulnerable decoder is exploitable as far as I can see.
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.
dany-ironsoftware commentedon Oct 8, 2026
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.
garyrknutson commentedon Oct 17, 2026
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.
dany-ironsoftware commentedon Oct 21, 2026
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:
FromBytes/FromStream/FromFile/ constructors)RotateFlipandRedactCreateMultiFrameTiff/CreateMultiFrameGifWe also added a public
IronSoftware.Drawing.ImageSharpLoader.Load(...). It's a drop-in replacement forImage.Load(...)for code that calls ImageSharp directly.Status of each advisory on .NET Framework (ImageSharp 2.1.13)
HistogramEqualizationout-of-bounds indexIccProfile.Entriesis read, and System.Drawing never reads it.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:
ImageSharpLoader.Load(...)instead ofImage.Load(...)HistogramEqualization, the CCITTTiffEncodercompressions andIccProfile.EntriesSummary
We have handled every part of these advisories that System.Drawing can reach on .NET Framework:
Could you try upgrading to IronSoftware.System.Drawing 2026.11.4 and let us know whether it works for you?
garyrknutson commentedon Oct 27, 2026
Hi @dany-ironsoftware, thanks for the detailed update.
I am not seeing IronSoftware.System.Drawing 2026.11.4 available to download from nuget - https://www.nuget.org/packages/IronSoftware.System.Drawing? However, I do see it published in GitHub with the tag prerelease - https://github.com/iron-software/IronSoftware.System.Drawing/releases.
Do you know when IronSoftware.System.Drawing 2026.11.4 will become a release candidate? We have internal controls which will not allow us to download/install non-release candidate builds.
Thanks.
sydseter commentedon Oct 29, 2026
@dany-ironsoftware Are you sure you are not refering to 2026.11.3?
sydseter commentedon Oct 29, 2026
This is the email I received from your support team. So I guess your message here is inaccurate?
Hi ...., thanks for reaching out. Patched versions that fix the SixLabors.ImageSharp advisories are now available on NuGet:
Please update each Iron Software package you use to the version above. If you suppressed the advisories while waiting, remove the suppression after updating so your scanner can confirm the fix.
All the NuGet links are on our notice: https://help.ironsoftware.com/support/security-notice-sixlabors.imagesharp-vulnerabilities
If you use another Iron Software product, let me know and we'll arrange a patched release for it.
dany-ironsoftware commentedon Oct 30, 2026
@sydseter , @garyrknutson
Sorry for the confusion.
You’re correct that 2026.11.4 hasn’t been published to NuGet yet, but you can download it and test it directly from this repo.
To give you the current update, we recently built a newer version, 2026.11.5 as the stable release, and it is now published to NuGet. You can now upgrade to 2026.11.5 directly, or wait for the stable IronPDF release that references that Drawing version.
Please feel free to reach us out if you have any questions.
Thank you.
sydseter commentedon Oct 30, 2026
Can 2026.11.5 be exchanged with 2026.8.2 directly, or will that cause issues? Should I consider the update to be major, minor or patch update with regards to semver. Any breaking changes?
dany-ironsoftware commentedon Oct 30, 2026
Hi @sydseter,
We don't recommend replacing IronSoftware.System.Drawing 2026.8.2 with 2026.11.5 on its own, under your current IronPDF version. The new Drawing release moves to newer ImageSharp versions, and ImageSharp 4.x on .NET 8+ changed its API, so we had to update in IronPDF to match.
Instead, please upgrade IronPDF to 2026.11.1, which is now on NuGet. It references Drawing 2026.11.5 and brings it in automatically, so you don't need to reference Drawing yourself.
On semver: our versions are based on the release month (YYYY.M.build), not semver. Upgrading IronPDF doesn't change its public API. Just in case if your own code uses SixLabors.ImageSharp directly on .NET 8+, though, that code now runs on ImageSharp 4.x and may need updating.