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.

Affected: PyPI: Pillow

### 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…