<?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>Wed, 21 Oct 2026 08:50:14 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-112403</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-112403</link>
      <description>&lt;p&gt;Pillow is a Python imaging library. Prior to 13.0.0, Pillow&amp;#39;s JPEG decoder can write a full-width scanline into a buffer sized for a requested draft scale. ImagingJpegDecode does not verify libjpeg&amp;#39;s actual output width and component count after scaling is requested, and an 8-bit lossless SOF3 JPEG decoded by a build linked to libjpeg-turbo 3.x can ignore the requested downscaling geometry. An attacker can supply such a JPEG to an application that uses draft() or thumbnail() to request downscaling. This can corrupt heap memory, crash the process, or potentially allow code execution. Older libjpeg-turbo 2.x and IJG builds reject the SOF3 input. 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, Pillow&amp;#39;s JPEG decoder can write a full-width scanline into a buffer sized for a requested draft scale. ImagingJpegDecode does not verify libjpeg&amp;#39;s actual output width and component count after scaling is requested, and an 8-bit lossless SOF3 JPEG decoded by a build linked to libjpeg-turbo 3.x can ignore the requested downscaling geometry. An attacker can supply such a JPEG to an application that uses draft() or thumbnail() to request downscaling. This can corrupt heap memory, crash the process, or potentially allow code execution. Older libjpeg-turbo 2.x and IJG builds reject the SOF3 input. 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-112403</guid>
    </item>
    <item>
      <title>GHSA-8g5g-8vmr-9782 — Pillow: Heap buffer overflow in ImagingJpegDecode</title>
      <link>https://db.gcve.eu/vuln/ghsa-8g5g-8vmr-9782</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Pillow&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`JpegImageFile.draft()` — which `Image.thumbnail()` calls automatically — requests 1/2, 1/4 or 1/8 scaled JPEG output and shrinks `self._size` and the tile extents to match, so `_setimage()` allocates a single-row decode buffer of `ceil(W/s)` samples. `ImagingJpegDecode()` sets `cinfo.scale_num`/`scale_denom`, calls `jpeg_start_decompress()`, and then reads scanlines into that buffer without ever comparing `cinfo.output_width`, `cinfo.output_height` or `cinfo.out_color_components` against `state-&amp;gt;xsize`, `state-&amp;gt;ysize` and `state-&amp;gt;bits`.&lt;/p&gt;
&lt;p&gt;libjpeg-turbo 3.x decodes lossless (SOF3) JPEG, but hardwires lossless streams to no scaling — the requested `scale_denom` is silently discarded. It therefore returns full-width `W`-sample rows into a buffer sized for `ceil(W/s)`. Each `jpeg_read_scanlines()` call writes `(W - ceil(W/s)) x components` bytes past the end of the heap allocation, and the overflowing bytes are the decoded pixel values, which are byte-exact for an 8-bit grayscale lossless image.&lt;/p&gt;
&lt;p&gt;The input is a standards-compliant JPEG, so `Image.open(..., formats=[&amp;#34;JPEG&amp;#34;])` does not prevent it. Pillow&amp;#39;s Python SOF parser already accepts marker `0xFFC3` (&amp;#34;SOF3&amp;#34;, &amp;#34;Spatial lossless&amp;#34;) at 8-bit precision, so the file opens normally as a `JPEG` / mode `L` image at its full declared size.&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;At `e41083f383c9cd3db95de52564cc0b6452313d4a` (`main`, 2026-08-29):&lt;/p&gt;
&lt;p&gt;- `src/libImaging/JpegDecode.c:224-262` — `ImagingJpegDecode()`; `jpeg_start_decompress()` at :240,…&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&lt;/p&gt;
&lt;p&gt;`JpegImageFile.draft()` — which `Image.thumbnail()` calls automatically — requests 1/2, 1/4 or 1/8 scaled JPEG output and shrinks `self._size` and the tile extents to match, so `_setimage()` allocates a single-row decode buffer of `ceil(W/s)` samples. `ImagingJpegDecode()` sets `cinfo.scale_num`/`scale_denom`, calls `jpeg_start_decompress()`, and then reads scanlines into that buffer without ever comparing `cinfo.output_width`, `cinfo.output_height` or `cinfo.out_color_components` against `state-&amp;gt;xsize`, `state-&amp;gt;ysize` and `state-&amp;gt;bits`.&lt;/p&gt;
&lt;p&gt;libjpeg-turbo 3.x decodes lossless (SOF3) JPEG, but hardwires lossless streams to no scaling — the requested `scale_denom` is silently discarded. It therefore returns full-width `W`-sample rows into a buffer sized for `ceil(W/s)`. Each `jpeg_read_scanlines()` call writes `(W - ceil(W/s)) x components` bytes past the end of the heap allocation, and the overflowing bytes are the decoded pixel values, which are byte-exact for an 8-bit grayscale lossless image.&lt;/p&gt;
&lt;p&gt;The input is a standards-compliant JPEG, so `Image.open(..., formats=[&amp;#34;JPEG&amp;#34;])` does not prevent it. Pillow&amp;#39;s Python SOF parser already accepts marker `0xFFC3` (&amp;#34;SOF3&amp;#34;, &amp;#34;Spatial lossless&amp;#34;) at 8-bit precision, so the file opens normally as a `JPEG` / mode `L` image at its full declared size.&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;At `e41083f383c9cd3db95de52564cc0b6452313d4a` (`main`, 2026-08-29):&lt;/p&gt;
&lt;p&gt;- `src/libImaging/JpegDecode.c:224-262` — `ImagingJpegDecode()`; `jpeg_start_decompress()` at :240,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-8g5g-8vmr-9782</guid>
    </item>
  </channel>
</rss>
