<?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 23:28:47 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-112396 — Pillow: Heap use-after-free when encoding TIFF to an in-memory buffer</title>
      <link>https://db.gcve.eu/vuln/cve-2026-112396</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 11.3.0 until 13.0.0, Pillow has a heap use-after-free when libtiff rejects a tag while encoding TIFF data to an in-memory buffer. When an application saves attacker-influenced TIFF tags to BytesIO, libtiff can reject a tag during encoding in ImagingLibTiffEncode; the error path then frees the output buffer without closing or clearing the TIFF handle, and later cleanup flushes through the write callback into freed memory, which can crash the process and may enable code execution. 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 11.3.0 until 13.0.0, Pillow has a heap use-after-free when libtiff rejects a tag while encoding TIFF data to an in-memory buffer. When an application saves attacker-influenced TIFF tags to BytesIO, libtiff can reject a tag during encoding in ImagingLibTiffEncode; the error path then frees the output buffer without closing or clearing the TIFF handle, and later cleanup flushes through the write callback into freed memory, which can crash the process and may enable code execution. This issue is fixed in version 13.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-112396</guid>
    </item>
    <item>
      <title>GHSA-4rr5-89j8-mwwm — Pillow: Heap use-after-free when encoding TIFF to an in-memory buffer</title>
      <link>https://db.gcve.eu/vuln/ghsa-4rr5-89j8-mwwm</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: pillow&lt;/p&gt;
&lt;p&gt;### Summary
Saving an image as TIFF to an in-memory buffer can trigger a heap use-after-free if libtiff rejects a tag at encode time. When `TIFFWriteScanline` fails, the encoder frees its output buffer but leaves the libtiff handle open. Later, when the encoder object is torn down, `TIFFClose` flushes buffered bytes through the write callback and writes into the freed buffer. An application that re-encodes attacker-influenced images to TIFF in memory can be crashed and is a candidate for remote code execution.&lt;/p&gt;
&lt;p&gt;### Details
The failure path in `ImagingLibTiffEncode` frees `clientstate-&amp;gt;data` for the in-memory case but does not close the TIFF or null `clientstate-&amp;gt;tiff` (the file-descriptor branch just above it does set `tiff = NULL`):&lt;/p&gt;
&lt;p&gt;- `src/libImaging/TiffDecode.c:1041-1046`&lt;/p&gt;
&lt;p&gt;Teardown then calls `ImagingLibTiffEncodeCleanup`, which runs `TIFFClose(tiff)` because `tiff` is still set:&lt;/p&gt;
&lt;p&gt;- `src/encode.c:99-101`
- `src/libImaging/TiffDecode.c:955`&lt;/p&gt;
&lt;p&gt;`TIFFClose` flushes through `_tiffWriteProc`, which reallocs and memcpys into the freed `state-&amp;gt;data`:&lt;/p&gt;
&lt;p&gt;- `src/libImaging/TiffDecode.c:103-115`&lt;/p&gt;
&lt;p&gt;The Predictor tag is a convenient trigger: the floating-point predictor (value 3) is invalid for integer sample data, so libtiff aborts the write.&lt;/p&gt;
&lt;p&gt;### PoC
```python
import io
from PIL import Image&lt;/p&gt;
&lt;p&gt;# In-memory TIFF re-encode. libtiff rejects Predictor=3 (floating point) on integer
# data, so TIFFWriteScanline fails. The encoder frees clientstate-&amp;gt;data but leaves the
# TIFF open; cleanup&amp;#39;s TI…&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
Saving an image as TIFF to an in-memory buffer can trigger a heap use-after-free if libtiff rejects a tag at encode time. When `TIFFWriteScanline` fails, the encoder frees its output buffer but leaves the libtiff handle open. Later, when the encoder object is torn down, `TIFFClose` flushes buffered bytes through the write callback and writes into the freed buffer. An application that re-encodes attacker-influenced images to TIFF in memory can be crashed and is a candidate for remote code execution.&lt;/p&gt;
&lt;p&gt;### Details
The failure path in `ImagingLibTiffEncode` frees `clientstate-&amp;gt;data` for the in-memory case but does not close the TIFF or null `clientstate-&amp;gt;tiff` (the file-descriptor branch just above it does set `tiff = NULL`):&lt;/p&gt;
&lt;p&gt;- `src/libImaging/TiffDecode.c:1041-1046`&lt;/p&gt;
&lt;p&gt;Teardown then calls `ImagingLibTiffEncodeCleanup`, which runs `TIFFClose(tiff)` because `tiff` is still set:&lt;/p&gt;
&lt;p&gt;- `src/encode.c:99-101`
- `src/libImaging/TiffDecode.c:955`&lt;/p&gt;
&lt;p&gt;`TIFFClose` flushes through `_tiffWriteProc`, which reallocs and memcpys into the freed `state-&amp;gt;data`:&lt;/p&gt;
&lt;p&gt;- `src/libImaging/TiffDecode.c:103-115`&lt;/p&gt;
&lt;p&gt;The Predictor tag is a convenient trigger: the floating-point predictor (value 3) is invalid for integer sample data, so libtiff aborts the write.&lt;/p&gt;
&lt;p&gt;### PoC
```python
import io
from PIL import Image&lt;/p&gt;
&lt;p&gt;# In-memory TIFF re-encode. libtiff rejects Predictor=3 (floating point) on integer
# data, so TIFFWriteScanline fails. The encoder frees clientstate-&amp;gt;data but leaves the
# TIFF open; cleanup&amp;#39;s TI…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-4rr5-89j8-mwwm</guid>
    </item>
  </channel>
</rss>
