<?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, 23 Oct 2026 18:26:31 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-96637</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-96637</link>
      <description>&lt;p&gt;Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.seek() in src/PIL/SpiderImagePlugin.py reparses a later SPIDER stack frame and replaces self._size without rerunning Image._decompression_bomb_check(). A tiny file can use a safe first frame to pass Image.open() and then declare very large dimensions in a later mode F frame. Loading that frame allocates approximately four bytes per attacker-declared pixel and can consume multiple gigabytes of memory. This issue is fixed in version 13.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.seek() in src/PIL/SpiderImagePlugin.py reparses a later SPIDER stack frame and replaces self._size without rerunning Image._decompression_bomb_check(). A tiny file can use a safe first frame to pass Image.open() and then declare very large dimensions in a later mode F frame. Loading that frame allocates approximately four bytes per attacker-declared pixel and can consume multiple gigabytes of memory. This issue is fixed in version 13.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-96637</guid>
    </item>
    <item>
      <title>GHSA-g842-9rc4-69pw — Pillow: Decompression bomb check bypass in SpiderImagePlugin.seek() leads to unbounded allocation DoS</title>
      <link>https://db.gcve.eu/vuln/ghsa-g842-9rc4-69pw</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;## Summary
SpiderImagePlugin&amp;#39;s seek() bypasses the decompression bomb check, allowing a tiny (&amp;lt;1KB) crafted SPIDER stack file to trigger a multi-gigabyte allocation on im.load().&lt;/p&gt;
&lt;p&gt;## Affected versions
All versions up to and including current HEAD (v13.0.0.dev0, commit e7a7ea84)&lt;/p&gt;
&lt;p&gt;## Root cause
Image.open() runs Image._decompression_bomb_check(im.size) exactly once, in _open_core (src/PIL/Image.py:3668), right after the initial _open().&lt;/p&gt;
&lt;p&gt;SPIDER stack files are multi-frame: SpiderImageFile.seek(frame) (SpiderImagePlugin.py:179-190) computes an attacker-influenced stkoffset and calls self._open() AGAIN directly (line 190) — NOT through Image.open(). _open() re-parses a fresh 27-float header at that offset and reassigns:&lt;/p&gt;
&lt;p&gt;self._size = int(h[12]), int(h[2])      # SpiderImagePlugin.py:131&lt;/p&gt;
&lt;p&gt;straight from unvalidated header floats (isSpiderHeader only checks internal labrec*lenbyt==labbyt consistency, never bounds nsam/nrow). No bomb check runs on this new size.&lt;/p&gt;
&lt;p&gt;On the subsequent load(), ImageFile.load_prepare() (ImageFile.py:436-437) executes `self.im = Image.core.new(self.mode, self.size)` with the unchecked, attacker-chosen size. Mode is always &amp;#34;F&amp;#34; (4 bytes/pixel), so e.g. 40000x40000 = 6.4 GB.&lt;/p&gt;
&lt;p&gt;## Why this is a real bug
Sibling multi-frame plugins DO re-check on their alternate paths:
- GifImagePlugin.py:286 - Image._decompression_bomb_check(self._size) (in seek)
- TiffImagePlugin.py:1309 - Image._decompression_bomb_check(self._tile_size)
- IcnsImagePlugin.py:121/138, IcoI…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;## Summary
SpiderImagePlugin&amp;#39;s seek() bypasses the decompression bomb check, allowing a tiny (&amp;lt;1KB) crafted SPIDER stack file to trigger a multi-gigabyte allocation on im.load().&lt;/p&gt;
&lt;p&gt;## Affected versions
All versions up to and including current HEAD (v13.0.0.dev0, commit e7a7ea84)&lt;/p&gt;
&lt;p&gt;## Root cause
Image.open() runs Image._decompression_bomb_check(im.size) exactly once, in _open_core (src/PIL/Image.py:3668), right after the initial _open().&lt;/p&gt;
&lt;p&gt;SPIDER stack files are multi-frame: SpiderImageFile.seek(frame) (SpiderImagePlugin.py:179-190) computes an attacker-influenced stkoffset and calls self._open() AGAIN directly (line 190) — NOT through Image.open(). _open() re-parses a fresh 27-float header at that offset and reassigns:&lt;/p&gt;
&lt;p&gt;self._size = int(h[12]), int(h[2])      # SpiderImagePlugin.py:131&lt;/p&gt;
&lt;p&gt;straight from unvalidated header floats (isSpiderHeader only checks internal labrec*lenbyt==labbyt consistency, never bounds nsam/nrow). No bomb check runs on this new size.&lt;/p&gt;
&lt;p&gt;On the subsequent load(), ImageFile.load_prepare() (ImageFile.py:436-437) executes `self.im = Image.core.new(self.mode, self.size)` with the unchecked, attacker-chosen size. Mode is always &amp;#34;F&amp;#34; (4 bytes/pixel), so e.g. 40000x40000 = 6.4 GB.&lt;/p&gt;
&lt;p&gt;## Why this is a real bug
Sibling multi-frame plugins DO re-check on their alternate paths:
- GifImagePlugin.py:286 - Image._decompression_bomb_check(self._size) (in seek)
- TiffImagePlugin.py:1309 - Image._decompression_bomb_check(self._tile_size)
- IcnsImagePlugin.py:121/138, IcoI…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-g842-9rc4-69pw</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-96637</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-96637</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: pillow, Ubuntu:Pro:16.04:LTS: pillow, Ubuntu:Pro:18.04:LTS: pillow, Ubuntu:Pro:20.04:LTS: pillow, Ubuntu:Pro:20.04:LTS: pillow-python2, Ubuntu:22.04:LTS: pillow, Ubuntu:24.04:LTS: pillow, Ubuntu:26.10: pillow, Ubuntu:26.04:LTS: pillow&lt;/p&gt;
&lt;p&gt;(Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.s ...)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: pillow, Ubuntu:Pro:16.04:LTS: pillow, Ubuntu:Pro:18.04:LTS: pillow, Ubuntu:Pro:20.04:LTS: pillow, Ubuntu:Pro:20.04:LTS: pillow-python2, Ubuntu:22.04:LTS: pillow, Ubuntu:24.04:LTS: pillow, Ubuntu:26.10: pillow, Ubuntu:26.04:LTS: pillow&lt;/p&gt;
&lt;p&gt;(Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.s ...)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-96637</guid>
    </item>
  </channel>
</rss>
