<?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 00:10:43 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-96643</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-96643</link>
      <description>&lt;p&gt;Pillow is a Python imaging library. From 11.0.0 until 13.0.0, Exif.load() in src/PIL/Image.py repeatedly slices the remaining EXIF data while it begins with the six-byte Exif header. src/PIL/PngImagePlugin.py accepts an uncapped PNG eXIf chunk, so a file filled with repeated headers causes a new shrinking copy on every iteration and quadratic CPU work. The condition is reachable through Image.getexif(), Image._getexif(), and ImageOps.exif_transpose(), including common photo-upload rotation workflows. 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, Exif.load() in src/PIL/Image.py repeatedly slices the remaining EXIF data while it begins with the six-byte Exif header. src/PIL/PngImagePlugin.py accepts an uncapped PNG eXIf chunk, so a file filled with repeated headers causes a new shrinking copy on every iteration and quadratic CPU work. The condition is reachable through Image.getexif(), Image._getexif(), and ImageOps.exif_transpose(), including common photo-upload rotation workflows. 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-96643</guid>
    </item>
    <item>
      <title>GHSA-g4qv-2jxx-769h — Pillow: PNG eXIf chunk makes EXIF parsing run in quadratic time</title>
      <link>https://db.gcve.eu/vuln/ghsa-g4qv-2jxx-769h</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Pillow&lt;/p&gt;
&lt;p&gt;### Summary
  A PNG file with a large eXIf chunk full of repeated 6-byte markers makes Pillow&amp;#39;s EXIF parser take seconds of CPU instead of milliseconds. The cost grows with the square of the chunk size, so a normal small-photo-sized file is enough to cause real delay.&lt;/p&gt;
&lt;p&gt;### Details
  `Exif.load()` in `src/PIL/Image.py` strips a marker from the start of the EXIF data like this:&lt;/p&gt;
&lt;p&gt;```python
  while data and data.startswith(b&amp;#34;Exif\x00\x00&amp;#34;):
      data = data[6:]
  ```&lt;/p&gt;
&lt;p&gt;Each pass makes a new copy of the remaining data. A real camera writes this marker once, so this is not normally a problem.&lt;/p&gt;
&lt;p&gt;`chunk_eXIf()` in `src/PIL/PngImagePlugin.py` puts the raw PNG eXIf chunk straight into `info[&amp;#34;exif&amp;#34;]` with no size limit and no check of its content. PNG text chunks (tEXt, zTXt, iTXt) are capped with `MAX_TEXT_CHUNK` and `MAX_TEXT_MEMORY`. The eXIf chunk has no such cap.&lt;/p&gt;
&lt;p&gt;If the eXIf chunk is filled with repeated `Exif\x00\x00` markers instead of real EXIF data, the strip loop runs once per marker, copying a large buffer each time. This is a classic quadratic time bug.&lt;/p&gt;
&lt;p&gt;### Steps to reproduce
  This builds a small PNG in memory and times `Image.open().getexif()` on it. No external file needed.&lt;/p&gt;
&lt;p&gt;```python
  import time
  from io import BytesIO
  from PIL import Image, PngImagePlugin&lt;/p&gt;
&lt;p&gt;def chunk(cid, *data):
      fp = BytesIO()
      PngImagePlugin.putchunk(fp, cid, *data)
      return fp.getvalue()&lt;/p&gt;
&lt;p&gt;MAGIC = PngImagePlugin._MAGIC
  IHDR = chunk(b&amp;#34;IHDR&amp;#34;, PngImagePlugin.o32(1…&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
  A PNG file with a large eXIf chunk full of repeated 6-byte markers makes Pillow&amp;#39;s EXIF parser take seconds of CPU instead of milliseconds. The cost grows with the square of the chunk size, so a normal small-photo-sized file is enough to cause real delay.&lt;/p&gt;
&lt;p&gt;### Details
  `Exif.load()` in `src/PIL/Image.py` strips a marker from the start of the EXIF data like this:&lt;/p&gt;
&lt;p&gt;```python
  while data and data.startswith(b&amp;#34;Exif\x00\x00&amp;#34;):
      data = data[6:]
  ```&lt;/p&gt;
&lt;p&gt;Each pass makes a new copy of the remaining data. A real camera writes this marker once, so this is not normally a problem.&lt;/p&gt;
&lt;p&gt;`chunk_eXIf()` in `src/PIL/PngImagePlugin.py` puts the raw PNG eXIf chunk straight into `info[&amp;#34;exif&amp;#34;]` with no size limit and no check of its content. PNG text chunks (tEXt, zTXt, iTXt) are capped with `MAX_TEXT_CHUNK` and `MAX_TEXT_MEMORY`. The eXIf chunk has no such cap.&lt;/p&gt;
&lt;p&gt;If the eXIf chunk is filled with repeated `Exif\x00\x00` markers instead of real EXIF data, the strip loop runs once per marker, copying a large buffer each time. This is a classic quadratic time bug.&lt;/p&gt;
&lt;p&gt;### Steps to reproduce
  This builds a small PNG in memory and times `Image.open().getexif()` on it. No external file needed.&lt;/p&gt;
&lt;p&gt;```python
  import time
  from io import BytesIO
  from PIL import Image, PngImagePlugin&lt;/p&gt;
&lt;p&gt;def chunk(cid, *data):
      fp = BytesIO()
      PngImagePlugin.putchunk(fp, cid, *data)
      return fp.getvalue()&lt;/p&gt;
&lt;p&gt;MAGIC = PngImagePlugin._MAGIC
  IHDR = chunk(b&amp;#34;IHDR&amp;#34;, PngImagePlugin.o32(1…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-g4qv-2jxx-769h</guid>
    </item>
  </channel>
</rss>
