Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-10-06T18:16:52.650Z",
  "pubdate": "2026-10-06T18:16:52.650Z",
  "executiveSummary": "ImageSharp versions 4.0.0 through 4.1.2 contain an information disclosure vulnerability within the EXR decompression logic. The vulnerability arises from improper buffer management during the reconstruction of ZIP-compressed EXR image blocks.\nSpecifically, the ExrBaseDecompressor.UndoZipCompression function fails to adequately validate the length of inflated data against the required EXR block size. This flaw allows the decoder to process incomplete or undersized ZIP payloads while retaining remnant data from previous memory operations.\nAn attacker can exploit this by providing a specially crafted EXR file that triggers an incomplete decompression. If the application exposes the resulting pixel data to the user, the attacker can retrieve sensitive process-local memory content, such as image fragments processed in earlier operations.\nThis vulnerability poses a significant risk for applications that handle sensitive image data in multi-tenant or shared memory environments. Successful exploitation allows for unauthorized data access without requiring elevated privileges, as the vulnerability is triggered through the processing of a maliciously crafted input file. It is recommended to update to version 4.1.2 or later to address the insufficient validation of decompression buffers.",
  "technicalDetails": "The vulnerability resides within the ExrBaseDecompressor.UndoZipCompression method in the ImageSharp library, which is responsible for handling ZIP-compressed data blocks in EXR files. The root cause is a failure to enforce parity between the inflated data size and the expected EXR block size. When a ZIP-compressed block is decompressed, the library returns the resulting byte sequence to the caller.\nDuring the decompression process, the ZipExrCompression.Decompress method reconstructs the returned prefix of the decompressed data. However, the logic permits scenarios where the Inflate result is non-empty but shorter than the mandated EXR block size. Because ExrDecoderCore continues processing based on the expected block size—allocating buffers via Configuration.Default—the discrepancy between the actual decompressed bytes and the anticipated block size leads to a memory initialization failure.\nIn systems where Configuration.Default manages pooled buffers, these buffers may retain stale data from prior operations. When the decoder fails to fully populate the allocated buffer with new image data, the remaining space contains raw bytes belonging to previous, unrelated memory operations. These 'stale' bytes are subsequently interpreted as pixel data during the rendering or conversion pipeline of the EXR image.\nThe attack flow proceeds as follows: 1) The attacker uploads a crafted EXR file containing an intentionally undersized ZIP payload. 2) The ImageSharp decoder invokes ExrBaseDecompressor.UndoZipCompression, which returns insufficient data. 3) The ExrDecoderCore proceeds to construct the target pixel buffer using pre-allocated, potentially dirty memory from the Configuration.Default buffer pool. 4) The library treats the trailing stale memory as valid pixel information. 5) The application outputs the resulting image, allowing the attacker to inspect pixel data that includes sensitive fragments of previous process activity.\nThis vulnerability affects ImageSharp versions 4.0.0 through 4.1.2. The exploitation does not require authentication, as the flaw is inherent to the library's parsing logic, and is typically exposed via any application interface that accepts and renders EXR files. The post-exploitation impact is limited to information disclosure, as the attacker can only read, not modify, sensitive process memory."
}