<?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://vulnerability.circl.lu</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>Tue, 06 Oct 2026 09:31:33 +0000</lastBuildDate>
    <item>
      <title>BIT-pillow-2026-55380 — Pillow GdImageFile decompression bomb protection bypass</title>
      <link>https://vulnerability.circl.lu/vuln/bit-pillow-2026-55380</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: pillow&lt;/p&gt;
&lt;p&gt;Pillow is a Python imaging library. Prior to 12.3.0, PIL/GdImageFile.py GdImageFile._open() read image dimensions from the GD 2.x header and stored them in self._size without calling Image._decompression_bomb_check(), allowing a crafted .gd file to trigger excessive C-heap allocation when loaded. This issue is fixed in version 12.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: pillow&lt;/p&gt;
&lt;p&gt;Pillow is a Python imaging library. Prior to 12.3.0, PIL/GdImageFile.py GdImageFile._open() read image dimensions from the GD 2.x header and stored them in self._size without calling Image._decompression_bomb_check(), allowing a crafted .gd file to trigger excessive C-heap allocation when loaded. This issue is fixed in version 12.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bit-pillow-2026-55380</guid>
    </item>
    <item>
      <title>CVE-2026-55380 — Pillow GdImageFile decompression bomb protection bypass</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-55380</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. Prior to 12.3.0, PIL/GdImageFile.py GdImageFile._open() read image dimensions from the GD 2.x header and stored them in self._size without calling Image._decompression_bomb_check(), allowing a crafted .gd file to trigger excessive C-heap allocation when loaded. This issue is fixed in version 12.3.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. Prior to 12.3.0, PIL/GdImageFile.py GdImageFile._open() read image dimensions from the GD 2.x header and stored them in self._size without calling Image._decompression_bomb_check(), allowing a crafted .gd file to trigger excessive C-heap allocation when loaded. This issue is fixed in version 12.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-55380</guid>
    </item>
    <item>
      <title>GHSA-phj9-mv4w-65pm — Pillow `GdImageFile._open()`: image dimensions accepted without `_decompression_bomb_check()`</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-phj9-mv4w-65pm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;`PIL/GdImageFile.py` `GdImageFile._open()` reads image dimensions from the GD 2.x header and stores them in `self._size` without calling `Image._decompression_bomb_check()`. Because `GdImageFile` is **not registered with `Image.register_open()`**, it never passes through the standard `Image.open()` code path that enforces Pillow&amp;#39;s decompression bomb guard. The plugin exposes its own entry point — `PIL.GdImageFile.open(fp)` — which directly instantiates the class, fully bypassing the documented protection.&lt;/p&gt;
&lt;p&gt;**Vulnerable code (`PIL/GdImageFile.py` lines 50–61):**&lt;/p&gt;
&lt;p&gt;```python
def _open(self) -&amp;gt; None:
    s = self.fp.read(1037)
    if i16(s) not in [65534, 65535]:
        raise SyntaxError(&amp;#34;Not a valid GD 2.x .gd file&amp;#34;)
    self._mode = &amp;#34;P&amp;#34;
    self._size = i16(s, 2), i16(s, 4)   # ← unsigned 16-bit; max 65535 each
    # NO _decompression_bomb_check() call here ←
    ...
    self.tile = [ImageFile._Tile(&amp;#34;raw&amp;#34;, (0, 0) + self.size, 1037, &amp;#34;L&amp;#34;)]
```&lt;/p&gt;
&lt;p&gt;When `load()` is subsequently called on the returned image object:&lt;/p&gt;
&lt;p&gt;```python
load() → load_prepare() → Image.core.new(&amp;#34;P&amp;#34;, (65535, 65535))
# ↑ C-level allocation of 4,294,836,225 bytes ≈ 4.3 GB — no Python bomb check precedes this
```&lt;/p&gt;
&lt;p&gt;**Dimension arithmetic:**&lt;/p&gt;
&lt;p&gt;| Field | Value |
|---|---|
| Maximum width from header | 65,535 (unsigned 16-bit) |
| Maximum height from header | 65,535 (unsigned 16-bit) |
| Maximum pixel count | 65,535 × 65,535 = **4,294,836,225** |
| `DecompressionBombError` threshold | 178,956,970 (2 × MA…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;## Description&lt;/p&gt;
&lt;p&gt;`PIL/GdImageFile.py` `GdImageFile._open()` reads image dimensions from the GD 2.x header and stores them in `self._size` without calling `Image._decompression_bomb_check()`. Because `GdImageFile` is **not registered with `Image.register_open()`**, it never passes through the standard `Image.open()` code path that enforces Pillow&amp;#39;s decompression bomb guard. The plugin exposes its own entry point — `PIL.GdImageFile.open(fp)` — which directly instantiates the class, fully bypassing the documented protection.&lt;/p&gt;
&lt;p&gt;**Vulnerable code (`PIL/GdImageFile.py` lines 50–61):**&lt;/p&gt;
&lt;p&gt;```python
def _open(self) -&amp;gt; None:
    s = self.fp.read(1037)
    if i16(s) not in [65534, 65535]:
        raise SyntaxError(&amp;#34;Not a valid GD 2.x .gd file&amp;#34;)
    self._mode = &amp;#34;P&amp;#34;
    self._size = i16(s, 2), i16(s, 4)   # ← unsigned 16-bit; max 65535 each
    # NO _decompression_bomb_check() call here ←
    ...
    self.tile = [ImageFile._Tile(&amp;#34;raw&amp;#34;, (0, 0) + self.size, 1037, &amp;#34;L&amp;#34;)]
```&lt;/p&gt;
&lt;p&gt;When `load()` is subsequently called on the returned image object:&lt;/p&gt;
&lt;p&gt;```python
load() → load_prepare() → Image.core.new(&amp;#34;P&amp;#34;, (65535, 65535))
# ↑ C-level allocation of 4,294,836,225 bytes ≈ 4.3 GB — no Python bomb check precedes this
```&lt;/p&gt;
&lt;p&gt;**Dimension arithmetic:**&lt;/p&gt;
&lt;p&gt;| Field | Value |
|---|---|
| Maximum width from header | 65,535 (unsigned 16-bit) |
| Maximum height from header | 65,535 (unsigned 16-bit) |
| Maximum pixel count | 65,535 × 65,535 = **4,294,836,225** |
| `DecompressionBombError` threshold | 178,956,970 (2 × MA…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-phj9-mv4w-65pm</guid>
    </item>
    <item>
      <title>PYSEC-2026-2256</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-2256</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;Pillow is a Python imaging library. Prior to 12.3.0, PIL/GdImageFile.py GdImageFile._open() read image dimensions from the GD 2.x header and stored them in self._size without calling Image._decompression_bomb_check(), allowing a crafted .gd file to trigger excessive C-heap allocation when loaded. This issue is fixed in version 12.3.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;Pillow is a Python imaging library. Prior to 12.3.0, PIL/GdImageFile.py GdImageFile._open() read image dimensions from the GD 2.x header and stored them in self._size without calling Image._decompression_bomb_check(), allowing a crafted .gd file to trigger excessive C-heap allocation when loaded. This issue is fixed in version 12.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-2256</guid>
    </item>
  </channel>
</rss>
