<?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>Thu, 01 Oct 2026 21:24:22 +0000</lastBuildDate>
    <item>
      <title>BIT-pillow-2026-59204 — Pillow JPEG2000 tiled decode retains a growing scratch buffer and can be used for denial of service</title>
      <link>https://vulnerability.circl.lu/vuln/bit-pillow-2026-59204</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. From 8.2.0 through 12.2.0, src/libImaging/Jpeg2KDecode.c accumulates total_component_width across every tile in a JPEG2000 image instead of recomputing it per tile, allowing a crafted tiled JPEG2000 file to force substantially higher transient memory usage and trigger out-of-memory failures during decoding. 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. From 8.2.0 through 12.2.0, src/libImaging/Jpeg2KDecode.c accumulates total_component_width across every tile in a JPEG2000 image instead of recomputing it per tile, allowing a crafted tiled JPEG2000 file to force substantially higher transient memory usage and trigger out-of-memory failures during decoding. 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-59204</guid>
    </item>
    <item>
      <title>CVE-2026-59204 — Pillow JPEG2000 tiled decode retains a growing scratch buffer and can be used for denial of service</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-59204</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.2.0 through 12.2.0, src/libImaging/Jpeg2KDecode.c accumulates total_component_width across every tile in a JPEG2000 image instead of recomputing it per tile, allowing a crafted tiled JPEG2000 file to force substantially higher transient memory usage and trigger out-of-memory failures during decoding. 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. From 8.2.0 through 12.2.0, src/libImaging/Jpeg2KDecode.c accumulates total_component_width across every tile in a JPEG2000 image instead of recomputing it per tile, allowing a crafted tiled JPEG2000 file to force substantially higher transient memory usage and trigger out-of-memory failures during decoding. This issue is fixed in version 12.3.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-59204</guid>
    </item>
    <item>
      <title>GHSA-vjc4-5qp5-m44j — Pillow JPEG2000 tiled decode retains a growing scratch buffer and can be used for denial of service</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-vjc4-5qp5-m44j</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;### Summary
`src/libImaging/Jpeg2KDecode.c:853` accumulates `total_component_width` across every tile in a JPEG2000 image instead of recomputing it per tile. That accumulated value is then used in the `tile_bytes` calculation at `src/libImaging/Jpeg2KDecode.c:868`, which can make the decoder grow `state-&amp;gt;buffer` via `realloc` at `src/libImaging/Jpeg2KDecode.c:876` up to roughly one full image&amp;#39;s decompressed size even when each tile is small. A crafted tiled JPEG2000 file can therefore force substantially higher transient memory usage and trigger out-of-memory failures during decoding. Based on current evidence, the supported impact is denial of service, not memory corruption.&lt;/p&gt;
&lt;p&gt;### Details
- Location: `src/libImaging/Jpeg2KDecode.c:853`
- Root cause: `total_component_width` is initialized only once before the tile loop and keeps growing across tiles. It is then used to derive `tile_bytes`, so later tiles are treated as if they had the combined component width of all earlier tiles.
- Dangerous operation: `tile_bytes` is promoted into `tile_info.data_size`, then `state-&amp;gt;buffer` is grown with `realloc` at `src/libImaging/Jpeg2KDecode.c:876`.
- Reachability: any attacker-controlled JPEG2000 image with many tiles reaches this path during normal `Image.open(...).load()` decoding.&lt;/p&gt;
&lt;p&gt;### PoC
The attached helper script and testcase were used:
[exercise_j2k_tile_realloc.zip](https://github.com/user-attachments/files/28099912/exercise_j2k_tile_realloc.zip)&lt;/p&gt;
&lt;p&gt;Generate the testcase:&lt;/p&gt;
&lt;p&gt;```b…&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
`src/libImaging/Jpeg2KDecode.c:853` accumulates `total_component_width` across every tile in a JPEG2000 image instead of recomputing it per tile. That accumulated value is then used in the `tile_bytes` calculation at `src/libImaging/Jpeg2KDecode.c:868`, which can make the decoder grow `state-&amp;gt;buffer` via `realloc` at `src/libImaging/Jpeg2KDecode.c:876` up to roughly one full image&amp;#39;s decompressed size even when each tile is small. A crafted tiled JPEG2000 file can therefore force substantially higher transient memory usage and trigger out-of-memory failures during decoding. Based on current evidence, the supported impact is denial of service, not memory corruption.&lt;/p&gt;
&lt;p&gt;### Details
- Location: `src/libImaging/Jpeg2KDecode.c:853`
- Root cause: `total_component_width` is initialized only once before the tile loop and keeps growing across tiles. It is then used to derive `tile_bytes`, so later tiles are treated as if they had the combined component width of all earlier tiles.
- Dangerous operation: `tile_bytes` is promoted into `tile_info.data_size`, then `state-&amp;gt;buffer` is grown with `realloc` at `src/libImaging/Jpeg2KDecode.c:876`.
- Reachability: any attacker-controlled JPEG2000 image with many tiles reaches this path during normal `Image.open(...).load()` decoding.&lt;/p&gt;
&lt;p&gt;### PoC
The attached helper script and testcase were used:
[exercise_j2k_tile_realloc.zip](https://github.com/user-attachments/files/28099912/exercise_j2k_tile_realloc.zip)&lt;/p&gt;
&lt;p&gt;Generate the testcase:&lt;/p&gt;
&lt;p&gt;```b…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-vjc4-5qp5-m44j</guid>
    </item>
    <item>
      <title>PYSEC-2026-3496 — Pillow JPEG2000 tiled decode retains a growing scratch buffer and can be used for denial of service</title>
      <link>https://vulnerability.circl.lu/vuln/pysec-2026-3496</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;### Summary
`src/libImaging/Jpeg2KDecode.c:853` accumulates `total_component_width` across every tile in a JPEG2000 image instead of recomputing it per tile. That accumulated value is then used in the `tile_bytes` calculation at `src/libImaging/Jpeg2KDecode.c:868`, which can make the decoder grow `state-&amp;gt;buffer` via `realloc` at `src/libImaging/Jpeg2KDecode.c:876` up to roughly one full image&amp;#39;s decompressed size even when each tile is small. A crafted tiled JPEG2000 file can therefore force substantially higher transient memory usage and trigger out-of-memory failures during decoding. Based on current evidence, the supported impact is denial of service, not memory corruption.&lt;/p&gt;
&lt;p&gt;### Details
- Location: `src/libImaging/Jpeg2KDecode.c:853`
- Root cause: `total_component_width` is initialized only once before the tile loop and keeps growing across tiles. It is then used to derive `tile_bytes`, so later tiles are treated as if they had the combined component width of all earlier tiles.
- Dangerous operation: `tile_bytes` is promoted into `tile_info.data_size`, then `state-&amp;gt;buffer` is grown with `realloc` at `src/libImaging/Jpeg2KDecode.c:876`.
- Reachability: any attacker-controlled JPEG2000 image with many tiles reaches this path during normal `Image.open(...).load()` decoding.&lt;/p&gt;
&lt;p&gt;### PoC
The attached helper script and testcase were used:
[exercise_j2k_tile_realloc.zip](https://github.com/user-attachments/files/28099912/exercise_j2k_tile_realloc.zip)&lt;/p&gt;
&lt;p&gt;Generate the testcase:&lt;/p&gt;
&lt;p&gt;```b…&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
`src/libImaging/Jpeg2KDecode.c:853` accumulates `total_component_width` across every tile in a JPEG2000 image instead of recomputing it per tile. That accumulated value is then used in the `tile_bytes` calculation at `src/libImaging/Jpeg2KDecode.c:868`, which can make the decoder grow `state-&amp;gt;buffer` via `realloc` at `src/libImaging/Jpeg2KDecode.c:876` up to roughly one full image&amp;#39;s decompressed size even when each tile is small. A crafted tiled JPEG2000 file can therefore force substantially higher transient memory usage and trigger out-of-memory failures during decoding. Based on current evidence, the supported impact is denial of service, not memory corruption.&lt;/p&gt;
&lt;p&gt;### Details
- Location: `src/libImaging/Jpeg2KDecode.c:853`
- Root cause: `total_component_width` is initialized only once before the tile loop and keeps growing across tiles. It is then used to derive `tile_bytes`, so later tiles are treated as if they had the combined component width of all earlier tiles.
- Dangerous operation: `tile_bytes` is promoted into `tile_info.data_size`, then `state-&amp;gt;buffer` is grown with `realloc` at `src/libImaging/Jpeg2KDecode.c:876`.
- Reachability: any attacker-controlled JPEG2000 image with many tiles reaches this path during normal `Image.open(...).load()` decoding.&lt;/p&gt;
&lt;p&gt;### PoC
The attached helper script and testcase were used:
[exercise_j2k_tile_realloc.zip](https://github.com/user-attachments/files/28099912/exercise_j2k_tile_realloc.zip)&lt;/p&gt;
&lt;p&gt;Generate the testcase:&lt;/p&gt;
&lt;p&gt;```b…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/pysec-2026-3496</guid>
    </item>
  </channel>
</rss>
