Pillow fixed a critical argument-injection flaw in its EPS handling on 16 October, released as version 13.0.0. The payload is not in the image. It is in the filename.
What happened
When Pillow opens an EPS file it shells out to Ghostscript. CVE-2026-112900 is an argument injection in that path: EpsImagePlugin.Ghostscript appends the caller-supplied filename after -f without turning it into a safe absolute path, so a name starting with a hyphen is read as a Ghostscript option instead of a file. A name starting with @ makes Ghostscript open it as an argument file and execute the arguments inside it, which is how the reported chain reaches command execution even with the default -dSAFER setting.
The CVE record, assigned by GitHub, scores it 9.2 under CVSS 4.0 and covers Pillow from 2.6.0 up to 13.0.0. Two conditions narrow it: the host must have the gs program installed, since Pillow needs Ghostscript to open EPS at all, and the attacker must control the filename being passed in. CISA's analysts record no known exploitation. The 13.0.0 release also fixes CVE-2026-112393, a buffer overflow when a compressed TIFF is saved to an in-memory buffer, and CVE-2026-112403, an overflow when thumbnailing a crafted lossless JPEG. Both are also scored 9.2. A separate FlashPix path in the same release reaches command execution from a single Image.open() call when the optional olefile package is installed.
Who is affected
- Python services that open images a user supplied: upload forms, avatar and thumbnail generators, document and PDF pipelines.
- Any host with Ghostscript installed that accepts EPS from untrusted users. The file itself can be benign, so content scanning will not catch it.
- Container images, wheels and base images that still bundle Pillow below 13.0.0. Bumping the dependency in your application code does not change what is already inside the image.
- Odoo and other Python business applications that install Pillow as a dependency, wherever the pinned version has been held back.
- Machine-learning stacks, which almost all pull Pillow in.
What to do now
Upgrade to Pillow 13.0.0, then rebuild every image that ships an older copy and confirm the version inside the running container.
- Run pip install -U "Pillow>=13.0.0" and pin the floor in your requirements file so the next build cannot fall back.
- Pillow 13 drops Python 3.10. Hosts still on 3.10 need Python 3.11 or newer before the upgrade.
- Remove the gs package from any host that processes user uploads where EPS is not a business requirement. That closes the reported chain outright.
- Stop passing user-supplied filenames into Image.open(). Store uploads under a generated name and open that path instead.
- Treat TIFF re-encoding into io.BytesIO as a sensitive code path, and avoid draft() or thumbnail() on untrusted JPEGs until you are on 13.0.0.
What this means for South African businesses
Nobody buys Pillow, which is exactly why its version goes unmanaged: it arrives as a dependency inside a web application or an Odoo install and no one owns the upgrade. In practice the exposure for a South African SME is narrow rather than sweeping. A plain WordPress site is not the target here, but a custom Python upload or thumbnail endpoint built a few years ago and still running an old base image is a realistic path to a shell on the server. The judgement call is to treat every internal Python tool that touches user files as in scope this week, even if no scan reports it.
Source: The Hacker News, critical flaw in Python's Pillow image library.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.