<?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:34 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-96639</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-96639</link>
      <description>&lt;p&gt;Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. This issue is fixed in version 13.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Pillow is a Python imaging library. From 11.0.0 until 13.0.0, multi-frame loaders can retain an ImagingCore allocation created for a narrow frame mode while a later frame of the same dimensions changes the logical mode and decoder tiles to wider RGB or CMYK data. ImageFile.load_prepare() reuses the stale native storage because _im is non-null without verifying that its mode and size still match. Crafted PSD, MPO, DCX, or MIC frame transitions can then write wider pixels into the narrow allocation, causing native out-of-bounds writes and crashes. The MPO path can also cause a native over-read and, in demonstrated runtime-specific profiles, command execution. 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-96639</guid>
    </item>
    <item>
      <title>GHSA-v9pv-5gc8-w2m6 — Pillow multi-frame loaders can reuse stale native image storage after mode transitions</title>
      <link>https://db.gcve.eu/vuln/ghsa-v9pv-5gc8-w2m6</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Pillow&lt;/p&gt;
&lt;p&gt;### Summary
Pillow multi-frame image loaders can retain native `ImagingCore` storage allocated for one frame while changing the Python-side image `mode` and decoder tiles for a later frame.&lt;/p&gt;
&lt;p&gt;If frame 0 allocates storage for a narrow mode such as `L`, and a later frame of the same dimensions switches to a wider mode such as `RGB` or `CMYK`, Pillow may decode wider pixels into the stale narrow native buffer. This causes native
out-of-bounds writes and process crashes. In the MPO/JPEG path, I also demonstrated command execution in matching Python/Pillow runtime profiles through Pillow&amp;#39;s documented `ImageSequence.Iterator` + `frame.load()` path.&lt;/p&gt;
&lt;p&gt;### Details
The root cause appears to be that `ImageFile.load_prepare()` only reallocates native storage when `_im is None`. It does not verify that the retained native `ImagingCore` storage still matches `self.mode` and `self.size`.&lt;/p&gt;
&lt;p&gt;Several multi-frame `seek()` / `_open()` paths can update `self._mode` and decoder tiles for a later frame without invalidating `_im`. The decoder then writes or reads according to the new frame mode while the native storage still belongs to the old frame mode.&lt;/p&gt;
&lt;p&gt;Verified affected surfaces:&lt;/p&gt;
&lt;p&gt;1. **PSD**&lt;/p&gt;
&lt;p&gt;`PsdImageFile.seek()` can switch from grayscale/native `L` storage to RGB layer decoding while retaining `_im`. This produces attacker-controlled native out-of-bounds writes and reliable crashes.&lt;/p&gt;
&lt;p&gt;2. **MPO/JPEG**&lt;/p&gt;
&lt;p&gt;A crafted two-frame MPO can make frame 0 allocate `L` storage, then make frame 1 decode `…&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
Pillow multi-frame image loaders can retain native `ImagingCore` storage allocated for one frame while changing the Python-side image `mode` and decoder tiles for a later frame.&lt;/p&gt;
&lt;p&gt;If frame 0 allocates storage for a narrow mode such as `L`, and a later frame of the same dimensions switches to a wider mode such as `RGB` or `CMYK`, Pillow may decode wider pixels into the stale narrow native buffer. This causes native
out-of-bounds writes and process crashes. In the MPO/JPEG path, I also demonstrated command execution in matching Python/Pillow runtime profiles through Pillow&amp;#39;s documented `ImageSequence.Iterator` + `frame.load()` path.&lt;/p&gt;
&lt;p&gt;### Details
The root cause appears to be that `ImageFile.load_prepare()` only reallocates native storage when `_im is None`. It does not verify that the retained native `ImagingCore` storage still matches `self.mode` and `self.size`.&lt;/p&gt;
&lt;p&gt;Several multi-frame `seek()` / `_open()` paths can update `self._mode` and decoder tiles for a later frame without invalidating `_im`. The decoder then writes or reads according to the new frame mode while the native storage still belongs to the old frame mode.&lt;/p&gt;
&lt;p&gt;Verified affected surfaces:&lt;/p&gt;
&lt;p&gt;1. **PSD**&lt;/p&gt;
&lt;p&gt;`PsdImageFile.seek()` can switch from grayscale/native `L` storage to RGB layer decoding while retaining `_im`. This produces attacker-controlled native out-of-bounds writes and reliable crashes.&lt;/p&gt;
&lt;p&gt;2. **MPO/JPEG**&lt;/p&gt;
&lt;p&gt;A crafted two-frame MPO can make frame 0 allocate `L` storage, then make frame 1 decode `…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-v9pv-5gc8-w2m6</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-96639</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-96639</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. From 11.0.0 until 13.0.0, multi-fr ...)&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. From 11.0.0 until 13.0.0, multi-fr ...)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-96639</guid>
    </item>
  </channel>
</rss>
