<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-08T16:00:16.837289+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-106111</id>
    <title>fkie_cve-2026-106111</title>
    <updated>2026-10-08T16:00:16.853535+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-106111"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-4q3p-rj5x-xv7p</id>
    <title>GHSA-4q3p-rj5x-xv7p — ImageSharp: EXR ZIP decoder can expose stale allocator data after a short inflate</title>
    <updated>2026-10-08T16:00:16.853620+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> NuGet: SixLabors.ImageSharp</p>
<p>## Summary</p>
<p>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.</p>
<p>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.</p>
<p>No active exploitation is known.</p>
<p>## Affected package and versions</p>
<p>- Package: `SixLabors.ImageSharp` (NuGet)
- Affected published releases: **4.0.0, 4.1.0, and 4.1.1**
- Affected range: `&gt;= 4.0.0, &lt;= 4.1.1`
- Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**.</p>
<p>EXR support first appears in v4.0.0. The cross-operation PoC exposes the prior-operation marker on each published 4.x release, while the full-inflate control does not expose it on any of them.
## Details</p>
<p>For ZIP/ZIPS EXR compression, [`ExrDecoderCore`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Formats/Exr/ExrDecoderCore.cs#L169-L205)
allocates the expected block buffer without `AllocationOptions.Clean` and later
interprets the complete buffer as channel data. [`ZipExrCompression`](https://github.com/SixLabors/ImageS…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-4q3p-rj5x-xv7p"/>
  </entry>
</feed>
