Skip to content
Heist/ feed
Back to feed
HighFix available

Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS

Type: advisorySources: OSV

``` ============================================================================ GIF seek keeps rejected size after DecompressionBombError, allowing DoS Location: src/PIL/GifImagePlugin.py:293 in GifImageFile._seek() Commit: a707c6b21c313880d0771e54965d142dd42358b6 ============================================================================ ``` A GIF of about 60 bytes can make Pillow allocate gigabytes of memory. This affects applications that catch the "image too large" error raised while stepping to a later animation frame and then keep using the same image object. Pillow correctly refuses the oversized frame, but it stores the refused dimensions on the image object anyway, and later operations size their memory from them. An attacker who can upload a GIF to such a service can exhaust its memory: the process either fails with an out-of-memory error after committing gigabytes, or is killed by the operating system. There is no memory corruption. The bug is in `GifImageFile._seek()` (`src/PIL/GifImagePlugin.py:292-294`). When a frame's extent enlarges the image, the code assigns the new size to `self._size` and only then calls `Image._decompression_bomb_check()`. Nothing restores the old size when `DecompressionBombError` is raised, because `seek()` only rolls back on `EOFError`. After the caught error, `im.size` reports the rejected size while the pixel buffer `im.im` is still the 1×1 first frame. Because the extent is a 16-bit offset plus a 16-bit size, that rejected size ca

Products
pillow
Affected versions
10.0.0, 10.0.1, 10.1.0, 10.2.0, 10.3.0, 10.4.0, 11.0.0, 11.1.0, 11.2.1, 11.3.0, 12.0.0, 12.1.0, 12.1.1, 12.2.0, 12.3.0, 9.2.0, 9.3.0, 9.4.0, 9.5.0
Fixed versions
13.0.0
CVEs
CVE-2026-112400
Confirmed fixed CVEs
Not specified
Updated in this feed
1 Nov 2026, 10:37 UTC · Revision 1

Source evidence

Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS

core-osv · Original source

Published 20 Oct 2026, 20:53 UTC

``` ============================================================================ GIF seek keeps rejected size after DecompressionBombError, allowing DoS Location: src/PIL/GifImagePlugin.py:293 in GifImageFile._seek() Commit: a707c6b21c313880d0771e54965d142dd42358b6 ============================================================================ ``` A GIF of about 60 bytes can make Pillow allocate gigabytes of memory. This affects applications that catch the "image too large" error raised while stepping to a later animation frame and then keep using the same image object. Pillow correctly refuses the oversized frame, but it stores the refused dimensions on the image object anyway, and later operations size their memory from them. An attacker who can upload a GIF to such a service can exhaust its memory: the process either fails with an out-of-memory error after committing gigabytes, or is killed by the operating system. There is no memory corruption. The bug is in `GifImageFile._seek()` (`src/PIL/GifImagePlugin.py:292-294`). When a frame's extent enlarges the image, the code assigns the new size to `self._size` and only then calls `Image._decompression_bomb_check()`. Nothing restores the old size when `DecompressionBombError` is raised, because `seek()` only rolls back on `EOFError`. After the caught error, `im.size` reports the rejected size while the pixel buffer `im.im` is still the 1×1 first frame. Because the extent is a 16-bit offset plus a 16-bit size, that rejected size ca

osv:GHSA-65qm-jvmh-6pqg

pillow

Fixed versions: 13.0.0

Complete source record
{
  "id": "5ba75c8649936b79aa6fcb4730983cd85c4bee5e16479a78a20719da137a417c",
  "url": "https://osv.dev/vulnerability/GHSA-65qm-jvmh-6pqg",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "Pillow: GIF seek keeps rejected size after DecompressionBombError, allowing DoS",
    "summary": "``` ============================================================================ GIF seek keeps rejected size after DecompressionBombError, allowing DoS Location: src/PIL/GifImagePlugin.py:293 in GifImageFile._seek() Commit: a707c6b21c313880d0771e54965d142dd42358b6 ============================================================================ ``` A GIF of about 60 bytes can make Pillow allocate gigabytes of memory. This affects applications that catch the \"image too large\" error raised while stepping to a later animation frame and then keep using the same image object. Pillow correctly refuses the oversized frame, but it stores the refused dimensions on the image object anyway, and later operations size their memory from them. An attacker who can upload a GIF to such a service can exhaust its memory: the process either fails with an out-of-memory error after committing gigabytes, or is killed by the operating system. There is no memory corruption. The bug is in `GifImageFile._seek()` (`src/PIL/GifImagePlugin.py:292-294`). When a frame's extent enlarges the image, the code assigns the new size to `self._size` and only then calls `Image._decompression_bomb_check()`. Nothing restores the old size when `DecompressionBombError` is raised, because `seek()` only rolls back on `EOFError`. After the caught error, `im.size` reports the rejected size while the pixel buffer `im.im` is still the 1×1 first frame. Because the extent is a 16-bit offset plus a 16-bit size, that rejected size ca",
    "evidence": "osv:GHSA-65qm-jvmh-6pqg",
    "products": [
      {
        "name": {
          "value": "pillow",
          "evidence": "/affected/0/package/name"
        },
        "prerequisites": [],
        "fixed_versions": [
          {
            "value": "13.0.0",
            "evidence": "/affected/0/ranges"
          }
        ],
        "affected_versions": [
          {
            "value": "10.0.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "10.0.1",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "10.1.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "10.2.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "10.3.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "10.4.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "11.0.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "11.1.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "11.2.1",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "11.3.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "12.0.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "12.1.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "12.1.1",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "12.2.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "12.3.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "9.2.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "9.3.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "9.4.0",
            "evidence": "/affected/0/versions"
          },
          {
            "value": "9.5.0",
            "evidence": "/affected/0/versions"
          }
        ]
      }
    ],
    "severity": "high",
    "structured": {
      "id": "GHSA-65qm-jvmh-6pqg",
      "aliases": [
        "BIT-pillow-2026-112400",
        "CVE-2026-112400",
        "GHSA-65qm-jvmh-6pqg"
      ],
      "metrics": [
        {
          "type": "CVSS_V4",
          "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "type": "ECOSYSTEM",
              "events": [
                {
                  "introduced": "9.2.0"
                },
                {
                  "fixed": "13.0.0"
                }
              ]
            }
          ],
          "package": {
            "name": "pillow",
            "purl": "pkg:pypi/pillow",
            "ecosystem": "PyPI"
          },
          "versions": [
            "10.0.0",
            "10.0.1",
            "10.1.0",
            "10.2.0",
            "10.3.0",
            "10.4.0",
            "11.0.0",
            "11.1.0",
            "11.2.1",
            "11.3.0",
            "12.0.0",
            "12.1.0",
            "12.1.1",
            "12.2.0",
            "12.3.0",
            "9.2.0",
            "9.3.0",
            "9.4.0",
            "9.5.0"
          ],
          "database_specific": {
            "source": "https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/10/GHSA-65qm-jvmh-6pqg/GHSA-65qm-jvmh-6pqg.json"
          }
        }
      ],
      "modified": "2026-10-26T08:55:49.781288748Z",
      "provider": "osv",
      "references": [
        "https://github.com/python-pillow/Pillow/security/advisories/GHSA-65qm-jvmh-6pqg",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-112400",
        "https://github.com/python-pillow/Pillow/commit/6faed707cfb760a4cbd726ddc8406f576cf35bf7",
        "https://github.com/python-pillow/Pillow",
        "https://github.com/python-pillow/Pillow/releases/tag/13.0.0"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-400"
        ],
        "severity": "HIGH",
        "github_reviewed": true,
        "nvd_published_at": "2026-10-19T22:17:07Z",
        "github_reviewed_at": "2026-10-20T20:53:36Z"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-112400",
        "evidence": "/aliases"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/database_specific/severity"
  },
  "source_id": "core-osv",
  "document_id": 446806,
  "published_at": "2026-10-20T20:53:36+00:00"
}