Pillow Flaw Lets a Filename Hijack Python Image Servers
A critical bug in Python's Pillow library turns an EPS filename into a Ghostscript command. Fixed in version 13.0.0.

Key points
- A critical flaw in Pillow, the image library used by most Python web apps, lets an attacker run commands on a server just by controlling the name of an uploaded EPS file.
- The bug, CVE-2026-112900, carries a CVSS severity score of 9.2 and was published on 19 October 2026.
- Every Pillow release from 2.6.0 up to but not including 13.0.0 is affected, and the maintainers' security advisory says the fix is in 13.0.0.
- Ghostscript's default
-dSAFERsandbox does not block the injection; the researchers' chain reproduces with Pillow's standard settings. - Full command execution needs a second step: a filename starting with
@that points at an attacker-controlled text file of Ghostscript arguments.
A new flaw in Pillow, the image-handling library behind a large share of Python web applications, lets an attacker slip commands onto a server by controlling the name of a file the application opens.
The Python Pillow project disclosed the issue on 19 October 2026. It is tracked as CVE-2026-112900 and rated 9.2 out of 10 on the CVSS severity scale.
The bug sits in how Pillow opens EPS files, a PostScript-based image format. Pillow does not render EPS itself. It shells out to Ghostscript, a separate interpreter, and hands it the filename after a -f flag. The problem: Pillow passes that filename straight through, without first turning it into a safe absolute path.
Ghostscript treats any argument that starts with a hyphen as an option. So a file called -something is read as a command-line switch, not a filename. That is argument injection, catalogued as CWE-88 in the advisory.
On its own, that lets an attacker twist Ghostscript's behaviour. To get full command execution, the researcher's write-up describes a second step: a filename beginning with @, which tells Ghostscript to read further arguments from the file at that path. If the attacker also controls the contents of that text file, they control the full Ghostscript command line, and from there the server.
Why doesn't Ghostscript's sandbox stop this?
It does not stop it because the injection happens before the sandbox applies. Pillow invokes Ghostscript with -dSAFER, the default sandbox meant to block dangerous operations. The advisory is explicit that the reported chain reproduces with -dSAFER enabled, because the attacker is injecting Ghostscript's own options, not escaping from inside a script Ghostscript runs.
Who is actually at risk?
Any Python application that uses Pillow to open an EPS file whose name the attacker can influence. In practice that means file-upload features: avatar uploaders, document processors, print shops, publishing pipelines, anything that lets a user send in a file and then calls Pillow on the path it was saved to.
If your service only handles PNG or JPEG from trusted sources, the exposure is lower. If it accepts EPS or auto-detects image types, and the saved filename reflects anything the user supplied, treat this as urgent.
What should developers do now?
Upgrade Pillow to 13.0.0. The maintainers' advisory lists that as the fixed version, with every release from 2.6.0 onward vulnerable.
| Item | Value |
|---|---|
| CVE | CVE-2026-112900 |
| CVSS | 9.2 (Critical) |
| Affected | Pillow 2.6.0 to 12.x |
| Fixed in | Pillow 13.0.0 |
| Published | 19 October 2026 |
| Weakness | CWE-88 argument injection |
Short-term mitigations, for teams that cannot upgrade immediately: do not pass user-controlled filenames to Image.open for EPS content. Rename uploads to a server-generated name before Pillow touches them, and reject filenames beginning with - or @. Disabling EPS handling entirely is the cleanest option where the format is not needed.
My read, having watched Pillow advisories for years: the pattern here, trusting fp.name and handing it to a subprocess, is the kind of thing that tends to surface in other libraries once a proof of concept circulates. The Hacker News flagged the EPS path specifically, and that is the right place to look first, but anyone shipping Python image pipelines should audit their own subprocess calls this week.



