Pillow 13 Security Update Explained (October 2026): What Image Uploads Need Now

The file can attack the code that reads it. An image is a set of instructions for rebuilding pixels, and a crafted set can push the reader into a bug. The Pillow 13 security update, released as Pillow 13.0.0 on 16 October 2026, fixes 38 such problems, many of them in the code that reads image files.

Picture a common setup. A small online marketplace lets sellers upload product photos, and a Python backend makes thumbnails with Pillow. The setup is made up, but the bugs and versions below are real. Nobody on the team ever writes code that looks dangerous.

The seller's file arrives with any name, such as shoe.jpg. Pillow does not rely on the name. It reads the first bytes, guesses the format, and hands the file to that format's reader. A crafted file can steer Pillow into a reader you never meant to use.

Three kinds of failure follow. The worker can run out of memory and crash, which is a denial of service. It can spin at full CPU, in one reported case without end. In the worst case, a memory bug lets the attacker run their own commands on your server.

Five terms carry most of the advisories. Each one is explained here once and used the same way after.

• Decoder: the code that turns a file's compressed bytes back into pixels. Pillow has one per format, and most bugs live here.
• Heap overflow: the decoder writes past the end of the memory block it reserved. Nearby data gets overwritten, which can crash the process or hand control to an attacker.
• Decompression bomb: a small file that claims a huge picture. A few kilobytes can ask for gigabytes of memory once decoded.
• Frame and seek(): some formats hold several pictures, called frames. Calling seek(n) moves to frame n, and Pillow reads that frame's header again.
• olefile: an optional Python package that reads Microsoft's old compound file format. Pillow needs it for FlashPix (FPX) and MIC images.

It is Pillow 13.0.0, a major release that ships security fixes together with breaking changes. Its release notes list 2 critical, 13 high, 20 medium and 3 low entries. One critical entry covers two separate reports, so the table below shows three critical rows. The fixes landed in 13.0.0 only.

A major release, in Pillow's versioning policy, is one that can remove old features and drop Python versions that reached end of life. Pillow does this every October. This year it dropped Python 3.10 and removed several deprecated features.

Each advisory has a GHSA ID, which is GitHub's security advisory number. Many also have a CVE ID, the industry-wide number that scanners use. We matched each pair below against the CVE record or the OSV database before printing it.

The release notes group the FlashPix report and the lossless JPEG report into one critical entry. That fits the code, because one new size check in Pillow's JPEG decoder closes both.

The ones a stranger can trigger with a single uploaded file. Three groups stand out: memory-safety bugs in decoders, ways around the pixel limit, and the FlashPix bug that depends on olefile.

Memory bugs in multi-frame readers

The top critical advisory, CVE-2026-96639, affects readers that hold several frames. Each frame has a pixel mode, which sets how much memory each pixel needs. On 12.3.0 a reader could keep the memory sized for an earlier frame. If a later frame used a wider mode, such as RGB after grayscale, Pillow wrote it into the smaller block.

The fix in 13.0.0 is short. When a later frame has a different size or mode, Pillow now throws away the stored pixels instead of reusing them. The MPO, DCX, MIC and PSD readers all use this new rule.

The pixel limit only guarded the first frame

Pillow checks an image's width times height when Image.open() reads the header. On 12.3.0, the MPO, DCX, MIC and SPIDER readers re-read the header on seek() and never repeated that check. Pillow 13.0.0 adds the check to each of those seek() methods.

The advisories give the scale. An MPO file of about 3 MB reached about 763 MB of peak memory. In the SPIDER advisory's worked example, a file under 1 KB asks for about 6.4 GB, because the format stores 4 bytes per pixel.

Think of a courier depot guard who checks the label on the first box of every shipment. The label is the image header. The guard is Pillow's pixel check. The other boxes in the shipment are the later frames, and on 12.3.0 nobody read their labels.

Where the picture breaks: a real guard can open a box, but Pillow cannot know the true decoded size without decoding. It can only trust the header, so a check that runs at the right moment is all it has.

FlashPix needs olefile, which you may not know you have

The FlashPix bug, CVE-2026-112398, is reachable only when olefile is installed. Pillow then recognises FlashPix by its first bytes, so a file called photo.jpg can still reach the FlashPix reader. The advisory reports code execution.

A plain pip install pillow does not install olefile. You get it through the pillow[fpx] or pillow[mic] extras, or through another package that depends on it. We confirmed this on 13.0.0: FPX and MIC appear in Pillow's format list only when olefile imports.

You must upgrade to 13.0.0. As of 25 October 2026, every advisory we opened lists 13.0.0 as the only fixed version, and PyPI has no release after 12.3.0 on the 12 line.

Pillow's versioning policy does allow patch releases for security fixes. Nothing on PyPI shows one for these advisories. Recheck PyPI before you plan around a 12.3.1, because that could change.

The bigger trap is Python 3.10. Pillow 13.0.0 declares Requires-Python 3.11 or newer. On Python 3.10, pip simply picks the newest release that fits, which is the vulnerable 12.3.0, and prints no warning about it.

We checked this with pip download on a Python 3.10 target. Asking for pillow gave pillow-12.3.0. Asking for pillow==13.0.0 failed with "No matching distribution found for pillow==13.0.0". On a Python 3.11 target, the same command gave 13.0.0.

If you install Pillow from your Linux distribution instead of PyPI, the distribution decides when you get fixes. On 25 October 2026, Debian's tracker for CVE-2026-112398 showed only the unstable branch fixed, through 13.0.0.

Upgrade every environment that opens untrusted images to Pillow 13.0.0, after moving it to Python 3.11 or newer. Then add the three defences below, which help against the next batch of bugs too.

1. 1

   Find every copy of Pillow

   Check web servers, background workers, notebooks and container images. Run python -c "import PIL; print(PIL.__version__)" in each one.

2. 2

   Check the Python version

   Run python --version. If it prints 3.10 or older, upgrade Python first. Otherwise pip keeps installing 12.3.0 on Python 3.10, or 11.3.0 on 3.9, and both are vulnerable.

3. 3

   Run your tests on 12.3.0 with warnings as errors

   Use python -W error::DeprecationWarning -m pytest. Four of the six removed features we tested raise a warning on 12.3.0, so this finds most breakage early.

4. 4

   Pin and install 13.0.0

   Set pillow==13.0.0 in your requirements file and reinstall. Rebuild container images, because an old layer can keep the old wheel.

5. 5

   Remove olefile if you do not need it

   Run pip show olefile and read its Required-by line. If nothing needs it and no code of yours reads FlashPix or MIC files, uninstall it.

6. 6

   Harden the upload path

   Allow only the formats you need, reject images over a pixel budget, decode with load() inside a try block, and reject multi-frame files you do not need.

Most code needs no change at all. The release removes several deprecated features and changes three behaviours. Search your code for each one before you deploy.

Three API changes do not raise errors, so tests may miss them. ImageColor.getcolor() now returns premultiplied values for RGBa and La modes. Duplicate TIFF tags now keep the first value. Saving a tiny ICO without sizes now uses the image's own size.

It caps width times height before any pixels are decoded. On both 12.3.0 and 13.0.0 the default is 89,478,485 pixels, about 8.9 crore (89 million). Above that, Pillow warns. Above twice that, 178,956,970 pixels, it raises Image.DecompressionBombError.

The gap between the two numbers surprises people. A warning does not stop anything. In our test, a 15000 by 10000 image, 15 crore pixels, opened on default settings with only a warning.

We tested the rule with the limit lowered to 4,000 pixels. A 60 by 60 image opened quietly. A 70 by 70 image, 4,900 pixels, opened with a DecompressionBombWarning. A 100 by 100 image raised DecompressionBombError, because 10,000 is above 8,000.

You can turn the warning into an error with warnings.simplefilter("error", Image.DecompressionBombWarning). That filter is process-wide. In a web server, a plain size check in your own code is easier to reason about, and the helper below does that.

Setting Image.MAX_IMAGE_PIXELS = None turns the check off completely. Some tutorials suggest it to silence the warning. Never do that in a process that opens uploads.

Because verify() does not decode pixels, it cannot catch a broken or malicious pixel stream. Its docstring in 13.0.0 says it checks the file "without actually decoding the image data". In the 13.0.0 source, only the PNG reader adds real checks to it.

We cut a JPEG of about 40,000 bytes to 60% of its length and tested both calls. verify() returned with no exception. load() raised OSError: image file is truncated. A truncated PNG did fail verify(), which matches PNG having its own checks.

There is a second trap. After verify(), the same image object cannot be loaded. On both versions, calling load() after verify() raised an AssertionError, because verify() closes the file. The docstring says to reopen the file first.

So the useful pattern is simple. Open the file, check its size and format from the header, then call load() inside a try block. Any decoding error then happens in one place you control.

load() does not make a buggy decoder safe. It runs the decoder, which is exactly where the memory bugs live. Its value is that failures happen early, inside your error handling, rather than later inside a thumbnail call.

Early load() also matters for one advisory. The lossless JPEG bug, CVE-2026-112403, runs through the shrink-while-decoding shortcut that thumbnail() uses. Its advisory lists load() before thumbnail() as a workaround, which is a stopgap, not a reason to stay on 12.3.0.

Pass a list or tuple of format names, and Pillow tries only those readers. With formats=["JPEG", "PNG", "WEBP"], a GIF raised UnidentifiedImageError on both versions. Passing a plain string such as "PNG" raises TypeError: formats must be a list or tuple.

This blocks a whole class of bugs. FlashPix, SPIDER, DCX, PSD and TIFF readers are never reached, whatever the file is called. Many of the 38 entries in the release notes sit in TIFF, PDF, EPS, GIF, BMP and other readers that a photo upload never needs.

The MPO surprise

Allowing JPEG also allows MPO. MPO, short for Multi Picture Object, stores several JPEG pictures in one file. Pillow's JPEG reader hands such files to the MPO reader.

We saved a two-frame MPO and opened it with formats=["JPEG"]. Pillow returned an MpoImageFile with format MPO and n_frames 2, on both versions. MPO is one of the four formats named in the critical CVE-2026-96639.

This behaviour is undocumented as of 25 October 2026; pin your version and recheck it after upgrades. Read im.format after opening, and reject files with more than one frame unless you need animation.

For the marketplace, it combines the three defences: a format allowlist, a pixel budget checked from the header, and an early load() inside one error handler. It also refuses multi-frame files, so your code never calls seek() on an upload.

import io

from PIL import Image

ALLOWED = ("JPEG", "PNG", "WEBP")
MAX_PIXELS = 40_000_000  # 4 crore pixels; pick a limit for your app


class BadImage(Exception):
    pass


def read_upload(data: bytes) -> Image.Image:
    try:
        with Image.open(io.BytesIO(data), formats=ALLOWED) as im:
            if im.width * im.height > MAX_PIXELS:
                raise BadImage(f"{im.width}x{im.height} is too many pixels")
            if getattr(im, "n_frames", 1) > 1:
                raise BadImage(f"{im.format} with {im.n_frames} frames")
            im.load()  # decode every pixel now, inside this try
            return im.copy()
    except Image.DecompressionBombError:
        raise BadImage("decompression bomb") from None
    except (OSError, SyntaxError, ValueError) as e:
        raise BadImage(type(e).__name__) from None

We ran this helper on 12.3.0 and 13.0.0 with eight test files, and both versions gave the same results. The table shows what each file did.

What just happened? Every bad file failed with one exception type, BadImage, so the web layer can return a clean error. The same results on 12.3.0 show the helper works on either version. It still cannot fix a decoder bug inside load(), so the upgrade stays first.

For more safety, run image work in a separate worker process with a memory cap and a timeout. Then a crash or memory spike kills one worker, not the web server. Re-encode the accepted image as a fresh JPEG or PNG before you store it.

Ask the running environment, not the requirements file. Three commands cover it, and each has a clear expected output.

python -c "import PIL; print(PIL.__version__)"
# expected: 13.0.0

python -c "from PIL import Image; Image.init(); print('FPX' in Image.ID)"
# expected: False when olefile is not installed

pip install pip-audit
pip-audit -r requirements.txt --no-deps --disable-pip
# expected: no pillow lines in the output once pillow==13.0.0 is pinned

The audit tool, pip-audit, looks up each pinned package in a public vulnerability database. With pillow==12.3.0 it printed "Found 37 known vulnerabilities in 1 package" on 25 October 2026, each with fix version 13.0.0. That count can change as more CVEs are assigned.

Run the version command inside each container and worker, not only on your laptop. A worker image built last month can still carry 12.3.0 after the web server moved on.

Use it as a case study in handling untrusted files. Interviewers care less about the CVE numbers and more about how your design limits damage when a library bug appears.

1. 1

   Name the threat

   Uploaded images are attacker-controlled input. Decoders are complex native code, so they get memory bugs and decompression bombs.

2. 2

   Patch fast, with a plan for breaking changes

   The fix shipped only in a major version that dropped Python 3.10. Say you keep runtimes current so a security upgrade is not blocked.

3. 3

   Reduce what the decoder sees

   Allow a few formats, cap pixels from the header, reject extra frames and drop optional readers like FlashPix.

4. 4

   Contain the blast radius

   Decode in an isolated worker with memory and time limits. Keep raw uploads in separate storage and serve only re-encoded copies.

5. 5

   Detect and verify

   Run a dependency audit in CI, log rejected files, and check the running version in every service that decodes images.