Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The TIFF CCITT Group 4 (T6) encoder writes beyond its logical compressed-data buffer when encoding a 1-bit image. A valid 1×1 Group 4 TIFF decoded and re-encoded with the default `TiffEncoder` terminates the process with an unhandled exception. Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.1.0, <= 4.1.1` - Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release v4.1.1. The T6 compressor was introduced by commit `3c9eb470a07a15012c2a29ad84090dcc804a7975`, first released in v2.1.0, with the same `Width * rowsPerStrip` allocation and unchecked code writes. The 1×1 exploit terminates published v2.1.0 and v4.1.1; its uncompressed control succeeds. Source history shows no capacity fix through v4.1.1. Details…
Recommended action: Upgrade to 4.1.2 or 3.2.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A crafted ZIP-compressed OpenEXR image can return stale memory from a prior ImageSharp operation as decoded pixels. The ZIP decoder accepts a non-empty inflate result shorter than the EXR block's required size, then the EXR decoder reads the full expected block. This is a process-local, cross-operation information-disclosure defect. It is relevant when an application uses the shared Configuration.Default allocator for separate image operations and exposes pixels or output derived from a later attacker-controlled EXR decode. Whether that creates a network attack path depends on the host application. No active exploitation is known. Affected package and versions - Package: SixLabors.ImageSharp (NuGet) - Affected published releases: 4.0.0, 4.1.0, and 4.1.1 - Affected range: = 4.0.0, <= 4.1.1 - Commit 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1. EXR support first appears in v4.0.0. The cross-operation PoC exposes the prior-operation marker on each…
Recommended action: Upgrade to 4.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When ICC conversion is enabled, a malformed embedded ICC LUT16 profile with more than four output channels can corrupt memory during ImageSharp color conversion. The ICC parser accepts up to 15 CLUT output channels, while the conversion implementation stores intermediate values in Vector4. Affected package and versions - Package: SixLabors.ImageSharp (NuGet) - Affected published releases: 4.0.0, 4.1.0, and 4.1.1 - Affected range: = 4.0.0, <= 4.1.1 - Commit 0815358f9202a78bc7f3b83e19282dc3654b500f corresponds to release v4.1.1. The reproduced ColorProfileHandling.Convert path and the unsafe Vector4 LUT operations are present in v4.0.0 and unchanged through v4.1.1. The three-output control succeeds on all three published 4.x releases; the fifteen-output exploit terminates all three. Details IccClut accepts one through fifteen input and output channels. In the reproduced A2B0 LUT16 path, an attacker-controlled profile declares three input channels and fifteen output channels.…
Recommended action: Upgrade to 4.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`SixLabors.ImageSharp` 4.1.1 can spend an attacker-controlled duration decoding a small malformed BigTIFF. The BigTIFF IFD entry-count field is 64-bit. The reader iterates once per declared entry, but when fewer than 20 bytes remain for an entry, the entry read returns without advancing. A 24-byte input can therefore run billions of iterations without consuming input. One decoder invocation occupied one executing thread for more than five seconds in the tested environment. This report makes no worker-pool exhaustion claim. Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.0.0, Exe net8.0 enable enable /root/.nuget/packages/sixlabors.imagesharp/4.1.1/lib/net8.0/SixLabors.ImageSharp.dll /root/.nuget/packages/system.io.hashing/8.0.0/lib/net8.0/System.IO.Hashing.dll ``` Dockerfile: ```dockerfile FROM mcr.microsoft.com/dotnet/sdk:8.0 WORKDIR /work COPY wmxv.csproj Program.cs ./ RUN printf '%s\n' ' net8.0 ' > fetch.csproj \ &&…
Recommended action: Upgrade to 4.1.2 or 3.2.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ImageSharp's TIFF CCITT Group 3 (T4) encoder can write beyond its allocated compressed-data buffer when encoding narrow 1-bit images. The unchecked writes can corrupt process memory and terminate the process. This report concerns only the T4 `CcittGroup3Fax` encoder path. It replaces the prior, unrelated ICC content. Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.0.0, 0 ? args[0] : "exploit"; int width = mode == "control" ? 64 : 1; int height = args.Length > 1 ? int.Parse(args[1]) : 2000; Console.WriteLine($"mode={mode} width={width} height={height}"); using var image = new Image (width, height); for (int y = 0; y < image.Height; y++) for (int x = 0; x < image.Width; x++) image[x, y] = new L8((byte)(((x + y) & 1) == 0 ? 255 : 0)); var metadata = image.Frames.RootFrame.Metadata.GetTiffMetadata(); metadata.BitsPerPixel = TiffBitsPerPixel.Bit1; metadata.Compression = TiffCompression.CcittGroup3Fax; using var output = new…
Recommended action: Upgrade to 4.1.2 or 3.2.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`SixLabors.ImageSharp` can terminate a process when an application decodes an attacker-supplied 32-bit floating-point TIFF as `Image ` and applies `HistogramEqualization()`. An IEEE positive-infinity TIFF sample reaches a non-finite or otherwise out-of-range `HalfVector4` component, depending on the release. The histogram equalization path derives a luminance-based histogram index without validating that result, reaching an unsafe out-of-range access. This report covers `HistogramEqualization` only. It does not claim Adaptive Histogram Equalization or AutoLevel behavior. Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 2.0.0, Fatal error. System.AccessViolationException: Attempted to read or write protected memory. ... at SixLabors.ImageSharp.Processing.Processors.Normalization.GrayscaleLevelsRowOperation`1.Invoke ... at SixLabors.ImageSharp.Processing.HistogramEqualizationExtensions.HistogramEqualization Docker exit…
Recommended action: Upgrade to 4.1.2 or 3.2.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malformed embedded ICC profile can make ImageSharp allocate memory from attacker-controlled CLUT channel and grid dimensions before verifying that the declared CLUT values are present. In published v1 through v3 packages, the public lazy ICC parser allocates approximately 115 MB from the 200-byte test profile before rejecting the truncated tag. In published v4 packages, decoding with ICC conversion enabled requests an 860,934,420-byte managed float array from the same profile. Affected package and versions - Package: `SixLabors.ImageSharp` (NuGet) - Affected range: `>= 1.0.0-beta0001, = 4.0.0, BinaryPrimitives.WriteUInt32BigEndian(bytes.AsSpan(offset, 4), value); private static void U16(byte[] bytes, int offset, ushort value) => BinaryPrimitives.WriteUInt16BigEndian(bytes.AsSpan(offset, 2), value); private static void Ascii(byte[] bytes, int offset, string value) { for (int i = 0; i (1, 1); image.Metadata.IccProfile = new IccProfile(icc); using var output = new…
Recommended action: Upgrade to 4.1.2 or 3.2.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 4.1.1 or 3.2.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A specially crafted GIF file containing a malformed comment extension block (with a missing block terminator) can cause the ImageSharp GIF decoder to enter an infinite loop while attempting to skip the block. This leads to a denial of service. Applications processing untrusted GIF input should upgrade to a patched version. Patches The problem has been patched. All users are advised to upgrade to v3.1.11 or v2.1.11. Workarounds None.
Recommended action: Upgrade to 3.1.11 or 2.1.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An Out-of-bounds Write vulnerability has been found in the ImageSharp gif decoder, allowing attackers to cause a crash using a specially crafted gif. This can potentially lead to denial of service. Patches The problem has been patched. All users are advised to upgrade to v3.1.7 or v2.1.10. Workarounds None. References https://github.com/SixLabors/ImageSharp/issues/2859 https://github.com/SixLabors/ImageSharp/issues/2890
Recommended action: Upgrade to 3.1.7 or 2.1.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact What kind of vulnerability is it? Who is impacted? A vulnerability discovered in the ImageSharp library, where the processing of specially crafted files can lead to excessive memory usage in the Gif decoder. The vulnerability is triggered when ImageSharp attempts to process image files that are designed to exploit this flaw. Patches Has the problem been patched? What versions should users upgrade to? The problem has been patched. All users are advised to upgrade to v3.1.5 or v2.1.9. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Before calling Image.Decode(Async), use Image.Identify to determine the image dimensions in order to enforce a limit. References Are there any links users can visit to find out more? - https://github.com/SixLabors/ImageSharp/pull/2759 - https://github.com/SixLabors/ImageSharp/pull/2764 - https://github.com/SixLabors/ImageSharp/pull/2770 - ImageSharp: Security Considerations - ImageSharp.Web: Securing…
Recommended action: Upgrade to 3.1.5 or 2.1.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An Out-of-bounds Write vulnerability has been found in the ImageSharp gif decoder, allowing attackers to cause a crash using a specially crafted gif. This can potentially lead to denial of service. Patches The problem has been patched. All users are advised to upgrade to v3.1.5 or v2.1.9. Workarounds None. References https://github.com/SixLabors/ImageSharp/pull/2754 https://github.com/SixLabors/ImageSharp/pull/2756
Recommended action: Upgrade to 3.1.5 or 2.1.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A data leakage flaw was found in ImageSharp's JPEG and TGA decoders. This vulnerability is triggered when an attacker passes a specially crafted JPEG or TGA image file to a software using ImageSharp, potentially disclosing sensitive information from other parts of the software in the resulting image buffer. Patches The problem has been patched. All users are advised to upgrade to v3.1.4 or v2.1.8. Workarounds None References None
Recommended action: Upgrade to 3.1.4 or 2.1.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerability discovered in the ImageSharp library, where the processing of specially crafted files can lead to excessive memory usage in image decoders. The vulnerability is triggered when ImageSharp attempts to process image files that are designed to exploit this flaw. This flaw can be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on ImageSharp for image processing tasks. Users and administrators are advised to update to the latest version of ImageSharp that addresses this vulnerability to mitigate the risk of exploitation. Patches The problem has been patched. All users are advised to upgrade to v3.1.4 or v2.1.8. Workarounds Before calling Image.Decode(Async), use Image.Identify to determine the image dimensions in order to enforce a limit. References - ImageSharp: Security Considerations - ImageSharp.Web: Securing Processing Commands
Recommended action: Upgrade to 3.1.4 or 2.1.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A heap-use-after-free flaw was found in ImageSharp's InitializeImage() function of PngDecoderCore.cs file. This vulnerability is triggered when an attacker passes a specially crafted PNG image file to ImageSharp for conversion, potentially leading to information disclosure. Patches The problem has been patched. All users are advised to upgrade to v3.1.3 or v2.1.7. Workarounds None References None
Recommended action: Upgrade to 3.1.3 or 2.1.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.