CVE-2026-106111: ImageSharp: EXR ZIP decoder can expose stale allocator data after a short inflate
ImageSharp is a 2D graphics library. From 4.0.0 until 4.1.2, ExrBaseDecompressor.UndoZipCompression accepts a nonempty ZIP or ZIPS inflate result that is shorter than the EXR block's required size. ZipExrCompression.Decompress reconstructs the returned prefix while ExrDecoderCore processes the full expected block from a buffer obtained through Configuration.Default, allowing bytes retained from a completed prior ImageSharp operation to appear in decoded pixels. Applications that expose pixels or output from the later attacker-controlled EXR decode can disclose process-local image data. This issue is fixed in version 4.1.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ImageSharpto a version that resolves this vulnerability.Fixed in 4.1.2
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Applications using Six Labors ImageSharp versions 4.0.0 through 4.1.2 that decode attacker-controlled EXR files and expose decoded pixels or derived output are exposed. The disclosed data can come from a completed prior ImageSharp operation in the same process.
What does an attacker need to exploit it?
An attacker needs to supply a crafted EXR file using ZIP or ZIPS compression whose inflate result is nonempty but shorter than the required EXR block size. No privileges or user interaction are required according to the supplied vector.
Are default configurations affected?
Yes. The vulnerable decoder obtains its buffer through Configuration.Default, so the issue can occur under the default ImageSharp configuration when a malformed ZIP or ZIPS-compressed EXR is decoded.
What is the remediation?
Upgrade ImageSharp to version 4.1.2, which fixes the issue. Until upgrading is possible, avoid decoding untrusted EXR files, particularly ZIP or ZIPS-compressed inputs, in processes that handle sensitive images.