<?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>Thu, 22 Oct 2026 18:26:07 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-96642</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-96642</link>
      <description>&lt;p&gt;Pillow is a Python imaging library. Prior to 13.0.0, the TarIO initializer in src/PIL/TarIO.py accepts a negative octal member size and computes a backward seek that returns to the same 512-byte header. When the requested member name does not match, the parser repeatedly reads that header, consumes a full CPU core, and never returns. TarIO is reached only when an application directly uses PIL.TarIO.TarIO rather than the default Image.open() path. 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, the TarIO initializer in src/PIL/TarIO.py accepts a negative octal member size and computes a backward seek that returns to the same 512-byte header. When the requested member name does not match, the parser repeatedly reads that header, consumes a full CPU core, and never returns. TarIO is reached only when an application directly uses PIL.TarIO.TarIO rather than the default Image.open() path. 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-96642</guid>
    </item>
    <item>
      <title>GHSA-3j72-p6qg-6xp7 — Pillow: TarIO negative size field causes infinite CPU-spin loop</title>
      <link>https://db.gcve.eu/vuln/ghsa-3j72-p6qg-6xp7</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: Pillow&lt;/p&gt;
&lt;p&gt;### Summary
`TarIO.__init__` does not check that a tar header&amp;#39;s size field is positive. A crafted header with a negative size makes it seek backward onto itself. This causes an infinite loop that uses 100% CPU and never returns.&lt;/p&gt;
&lt;p&gt;### Details
`TarIO.__init__` reads 512-byte tar headers one at a time, looking for a member with a given name. For each header it reads the size field and skips ahead to the next header:&lt;/p&gt;
&lt;p&gt;```python
size = int(s[124:135], 8)
...
self.fh.seek((size + 511) &amp;amp; (~511), io.SEEK_CUR)
```
There is no check that size is zero or more. A tar header can set this field to a negative octal value. For size = -512, the seek offset comes out to exactly -512, which cancels the 512 bytes the loop had just read. The file position goes right back to where this loop step started.&lt;/p&gt;
&lt;p&gt;The loop only stops on end of file or when a header name starts with a null byte. Neither happens, since the same header keeps showing up again. The loop never ends on its own.&lt;/p&gt;
&lt;p&gt;### Steps to reproduce&lt;/p&gt;
&lt;p&gt;This uses Tests/images/hopper.tar, a normal file already in the Pillow test suite. It only changes the size field of the first header.&lt;/p&gt;
&lt;p&gt;```python
from PIL import TarIO&lt;/p&gt;
&lt;p&gt;with open(&amp;#34;Tests/images/hopper.tar&amp;#34;, &amp;#34;rb&amp;#34;) as f:
    data = bytearray(f.read())&lt;/p&gt;
&lt;p&gt;# Set the size field (bytes 124 to 135) to a negative octal value.
# Octal 1000 is 512, so this is size = -512.
data[124:135] = b&amp;#34;  -00001000&amp;#34;&lt;/p&gt;
&lt;p&gt;with open(&amp;#34;poisoned.tar&amp;#34;, &amp;#34;wb&amp;#34;) as f:
    f.write(data)&lt;/p&gt;
&lt;p&gt;# &amp;#34;does-not-exist&amp;#34; does not match the header name,…&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
`TarIO.__init__` does not check that a tar header&amp;#39;s size field is positive. A crafted header with a negative size makes it seek backward onto itself. This causes an infinite loop that uses 100% CPU and never returns.&lt;/p&gt;
&lt;p&gt;### Details
`TarIO.__init__` reads 512-byte tar headers one at a time, looking for a member with a given name. For each header it reads the size field and skips ahead to the next header:&lt;/p&gt;
&lt;p&gt;```python
size = int(s[124:135], 8)
...
self.fh.seek((size + 511) &amp;amp; (~511), io.SEEK_CUR)
```
There is no check that size is zero or more. A tar header can set this field to a negative octal value. For size = -512, the seek offset comes out to exactly -512, which cancels the 512 bytes the loop had just read. The file position goes right back to where this loop step started.&lt;/p&gt;
&lt;p&gt;The loop only stops on end of file or when a header name starts with a null byte. Neither happens, since the same header keeps showing up again. The loop never ends on its own.&lt;/p&gt;
&lt;p&gt;### Steps to reproduce&lt;/p&gt;
&lt;p&gt;This uses Tests/images/hopper.tar, a normal file already in the Pillow test suite. It only changes the size field of the first header.&lt;/p&gt;
&lt;p&gt;```python
from PIL import TarIO&lt;/p&gt;
&lt;p&gt;with open(&amp;#34;Tests/images/hopper.tar&amp;#34;, &amp;#34;rb&amp;#34;) as f:
    data = bytearray(f.read())&lt;/p&gt;
&lt;p&gt;# Set the size field (bytes 124 to 135) to a negative octal value.
# Octal 1000 is 512, so this is size = -512.
data[124:135] = b&amp;#34;  -00001000&amp;#34;&lt;/p&gt;
&lt;p&gt;with open(&amp;#34;poisoned.tar&amp;#34;, &amp;#34;wb&amp;#34;) as f:
    f.write(data)&lt;/p&gt;
&lt;p&gt;# &amp;#34;does-not-exist&amp;#34; does not match the header name,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-3j72-p6qg-6xp7</guid>
    </item>
  </channel>
</rss>
