Pillow EPS filename flaw lets attackers inject Ghostscript options

Pillow’s EPS plugin builds a Ghostscript command line using the filename from the image object without sanitizing it, according to the GitHub advisory for CVE-2026-112900. The path is inserted after the -f flag, and Ghostscript treats a leading - or -- as an option instead of a file. When the filename starts with @, Ghostscript interprets it as an argument-file token and loads extra command-line options from that file.

The flaw is in PIL.EpsImagePlugin.Ghostscript(), where infile = fp.name is used when the file exists. Pillow’s default -dSAFER setting does not prevent the argument injection, the advisory says. The core weakness is classified as CWE-88 argument injection, and it can become CWE-78 OS command injection when an attacker also controls the referenced @ file. Chanu Kang of CysecLab at KAIST reported the vulnerability and published a proof of concept.

In the proof of concept, a file named @arg plus a controlled text file caused Ghostscript to execute /bin/id when the image was loaded, demonstrating remote code execution. Kang tested this on Pillow 12.3.0 with Ghostscript 10.02.1 and confirmed RCE again with Ghostscript 10.07.1. The advisory says the vulnerable code is long-standing and appears in all current versions, including the main branch.

The advisory distinguishes this from the documented risk of malicious EPS content. The bug does not depend on anything inside the EPS file's content. Even an ordinary EPS file can trigger Ghostscript argument injection if the filename passed to Image.open() is attacker-controlled, so applications that legitimately process EPS are still exposed. File upload endpoints that preserve or derive stored names from user input are realistic entry points.

The advisory suggests normalizing the filename to an absolute path with os.path.abspath(fp.name) so a leading - or @ cannot reach Ghostscript’s argument parser. The else branch, which already creates a temporary file with tempfile.mkstemp(), is safe because that path does not start with - or @. Defenders should check for code paths that pass user-controlled filenames to Image.open() for EPS files and consider the advisory's suggested normalization.