<?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-08T22:45:31.181909+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-106114</id>
    <title>fkie_cve-2026-106114</title>
    <updated>2026-10-08T22:45:31.199933+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>ImageSharp is a 2D graphics library. From 1.0.0-beta0001 until 4.1.2, ICC CLUT parsing calculates allocation sizes from attacker-declared channel and grid dimensions before confirming that the profile contains the declared values. IccDataReader.ReadClutF32 can request a large float array, and earlier public IccProfile.Entries parsing paths can allocate a large jagged representation, from a short truncated profile. In version 4, automatic image conversion reaches the parser when DecoderOptions.ColorProfileHandling is Convert; the default Preserve mode avoids that conversion path. The demonstrated impact is memory pressure and input-validation failure, not unhandled process termination. This issue is fixed in version 4.1.2.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-106114"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-gwg2-r3hj-4w44</id>
    <title>GHSA-gwg2-r3hj-4w44 — ImageSharp: ICC CLUT parsing allocates from unvalidated channel and grid dimensions</title>
    <updated>2026-10-08T22:45:31.200002+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 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.</p>
<p>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.</p>
<p>### Affected package and versions</p>
<p>- Package: `SixLabors.ImageSharp` (NuGet)
- Affected range: `&gt;= 1.0.0-beta0001, &lt;= 4.1.1`
- Commit `0815358f9202a78bc7f3b83e19282dc3654b500f` corresponds to release **v4.1.1**.</p>
<p>The parser defect is present from the first published NuGet prerelease, `1.0.0-beta0001`, through the latest published release, 4.1.1. The automatic `Image.Load` conversion path used by the main PoC exists in `&gt;= 4.0.0, &lt;= 4.1.1`; earlier versions expose the same parser defect through the public `IccProfile.Entries` accessor.
### Details</p>
<p>The reproduced profile has an `A2B0` multi-process-elements (`mpet`) tag with a
`clut` element declaring 15 input channels, 15 output channels, and three grid
points per input channel. [`ReadClutF32`](https://github.com/SixLabors/ImageSharp/blob/0815358f9202a78bc7f3b83e19282dc3654b500f/src/ImageSharp/Metadata/Profiles/ICC/DataReader/IccDataReader.Lut.cs#L139-L162)
computes `3^15 * 15` and allocates that many floats before reading any CLUT
val…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-gwg2-r3hj-4w44"/>
  </entry>
</feed>
