<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 30 Oct 2026 02:34:00 +0000</lastBuildDate>
    <item>
      <title>BREW-aider-CVE-2026-112399 — Pillow: APNG background disposal allocates full canvas before decompression bomb check</title>
      <link>https://db.gcve.eu/vuln/brew-aider-cve-2026-112399</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: aider&lt;/p&gt;
&lt;p&gt;```
============================================================================
APNG background disposal allocates full canvas before decompression bomb check
Location: src/PIL/PngImagePlugin.py:1000  in PngImageFile._seek()
Commit:   a707c6b21c313880d0771e54965d142dd42358b6
============================================================================
```&lt;/p&gt;
&lt;p&gt;A 126-byte animated PNG file makes Pillow&amp;#39;s `Image.open()` allocate and fill memory sized by the image dimensions the file claims, before Pillow&amp;#39;s built-in check for oversized images runs. A file claiming 22000×22000 pixels costs about 1.9 GB. Anyone who can get an application to open an image they supply, with default settings and no further calls such as `load()`, can cause a multi-gigabyte memory spike per file. If the claimed size exceeds the machine&amp;#39;s free memory, the operating system kills the process outright.&lt;/p&gt;
&lt;p&gt;The bug is in `PngImageFile._seek()` in `src/PIL/PngImagePlugin.py` (around line 1000). For any APNG, `_open()` calls `self._seek(0)`. When the first `fcTL` chunk requests `OP_BACKGROUND` disposal, `_seek()` calls `Image.core.fill(self.mode, self.size)` with the full IHDR size, which allocates and zero-fills width×height×4 bytes. `OP_PREVIOUS` takes the same path, because frame 0 rewrites it to `OP_BACKGROUND`. This all happens inside the plugin factory, so `Image.open()`&amp;#39;s `_decompression_bomb_check(im.size)` only runs after the memory has been touched. A 1×1 frame rectangle passes the only checks on the way…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: aider&lt;/p&gt;
&lt;p&gt;```
============================================================================
APNG background disposal allocates full canvas before decompression bomb check
Location: src/PIL/PngImagePlugin.py:1000  in PngImageFile._seek()
Commit:   a707c6b21c313880d0771e54965d142dd42358b6
============================================================================
```&lt;/p&gt;
&lt;p&gt;A 126-byte animated PNG file makes Pillow&amp;#39;s `Image.open()` allocate and fill memory sized by the image dimensions the file claims, before Pillow&amp;#39;s built-in check for oversized images runs. A file claiming 22000×22000 pixels costs about 1.9 GB. Anyone who can get an application to open an image they supply, with default settings and no further calls such as `load()`, can cause a multi-gigabyte memory spike per file. If the claimed size exceeds the machine&amp;#39;s free memory, the operating system kills the process outright.&lt;/p&gt;
&lt;p&gt;The bug is in `PngImageFile._seek()` in `src/PIL/PngImagePlugin.py` (around line 1000). For any APNG, `_open()` calls `self._seek(0)`. When the first `fcTL` chunk requests `OP_BACKGROUND` disposal, `_seek()` calls `Image.core.fill(self.mode, self.size)` with the full IHDR size, which allocates and zero-fills width×height×4 bytes. `OP_PREVIOUS` takes the same path, because frame 0 rewrites it to `OP_BACKGROUND`. This all happens inside the plugin factory, so `Image.open()`&amp;#39;s `_decompression_bomb_check(im.size)` only runs after the memory has been touched. A 1×1 frame rectangle passes the only checks on the way…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/brew-aider-cve-2026-112399</guid>
    </item>
    <item>
      <title>CVE-2026-112399 — Pillow: APNG background disposal allocates full canvas before decompression bomb check</title>
      <link>https://db.gcve.eu/vuln/cve-2026-112399</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; python-pillow Pillow&lt;/p&gt;
&lt;p&gt;Pillow is a Python imaging library. From 8.1.0 until 13.0.0, Pillow can allocate an APNG disposal background at the full canvas size before applying the decompression-bomb check. A crafted APNG with a small first frame, a very large declared canvas, and background disposal or first-frame OP_PREVIOUS reaches PngImageFile._seek while Image.open() positions frame zero. The full-canvas allocation occurs inside Image.open() without requiring pixel loading or frame iteration. This can exhaust memory and deny service. This issue is fixed in version 13.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; python-pillow Pillow&lt;/p&gt;
&lt;p&gt;Pillow is a Python imaging library. From 8.1.0 until 13.0.0, Pillow can allocate an APNG disposal background at the full canvas size before applying the decompression-bomb check. A crafted APNG with a small first frame, a very large declared canvas, and background disposal or first-frame OP_PREVIOUS reaches PngImageFile._seek while Image.open() positions frame zero. The full-canvas allocation occurs inside Image.open() without requiring pixel loading or frame iteration. This can exhaust memory and deny service. This issue is fixed in version 13.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-112399</guid>
    </item>
  </channel>
</rss>
