WeasyPrint: EPS images reach the Ghostscript interpreter resulting in RCE

Summary

This was found during a pentest, funded by the NLNnet foundation, conducted by Stefan Vink from Radically Open Security and the only High issue found.

WeasyPrint passes fetched image bytes directly to Pillow's generic format dispatcher without restricting the input format. When Ghostscript is installed on the host, Pillow's EpsImagePlugin invokes it to rasterize attacker-controlled EPS/PS input. Any content that can supply an image to WeasyPrint (an <img> URL, CSS image value, SVG image reference, or data URI) can therefore drive untrusted PostScript into an external interpreter. On hosts running a Ghostscript version with a known -dSAFER bypass, this yields remote code execution.

Details

The image pipeline reads an external response and hands the raw bytes to Pillow's format-agnostic Image.open, with no allowlist of safe raster formats:

with fetch(url_fetcher, url) as response: bytestring = response.read() mime_type = forced_mime_type or response.content_type

...

pillow_image = Image.open(BytesIO(bytestring))

Pillow selects the handler from the byte signature. For EPS/PS input it selects PIL.EpsImagePlugin, which invokes Ghostscript to rasterize the input when a Ghostscript executable is available. Modern Ghostscript builds may run with -dSAFER, but that does not remove the interpreter boundary — it only constrains it, and multiple CVEs have bypassed it.

The defect in WeasyPrint is that it dispatches untrusted bytes to a format handler capable of invoking an external interpreter, without first validating that the input is a format whose safe handling WeasyPrint can guarantee.

• Input: an image URL in <img>, a CSS image value, an SVG image reference, or a data URI.
• Sink: the Ghostscript invocation inside Pillow's PIL.EpsImagePlugin, reached from weasyprint/images.py:287-327.

Missing guards:

• No allowlist limits image input to safe raster formats (e.g. PNG, JPEG, WebP) before Pillow's format dispatch.
• No interpreter-specific CPU, memory, filesystem, or process-isolation guard exists in this path.

Hosts without Ghostscript installed do not reach the EPS rasterization path; that is an environment dependency, not an input-format guard within WeasyPrint.

PoC

1. Construct a minimal EPS payload that proves the Ghostscript subprocess executes attacker-supplied PostScript. The following 201-byte payload writes a marker file:

postscript %!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: 0 0 100 100 (/tmp/test-marker.txt) (w) file dup (test_GHOSTSCRIPT_MARKER\n) writestring closefile 0.5 setgray 0 0 100 100 rectfill showpage %%EOF

1. The path /tmp/test-marker.txt is illustrative; a hardened reproduction writes the marker into a unique mode-0700 directory created with tempfile.mkdtemp. The write destination exists only to prove the Ghostscript subprocess executed user-supplied PostScript.