CVE-2026-106443: Remote Code Execution in WeasyPrint via Unvalidated Pillow EPS Processing

WeasyPrint is a widely deployed pythonic document generation library designed to compile structured HTML documents and CSS stylesheets into print-ready PDF files. Web developers frequently integrate this component within backend architectures to dynamically generate user-facing assets such as financial invoices, corporate statements, medical records, and custom resumes. Due to the nature of document compilation, WeasyPrint exposes a significant network attack surface, as it must fetch and render external multi-media assets, including vector and raster images, over the network or from internal directories.

During a comprehensive, NLNet foundation-funded security audit executed by Radically Open Security researcher Stefan Vink, a critical validation flaw was identified in WeasyPrint's image processing component. The vulnerability, tracked as CVE-2026-106443, resides in the way WeasyPrint's fetching module processes external files. Instead of validating incoming media assets against a strict list of safe MIME types, WeasyPrint forwards raw, unvalidated byte arrays directly to Pillow's (PIL) generic file loader, enabling an attacker to dispatch malicious files to hazardous backend parsers.

When WeasyPrint processes an input HTML document containing a malicious Encapsulated PostScript (EPS) file, the Pillow library automatically matches the magic bytes of the file and invokes its internal EPS renderer. If the underlying host environment contains an active installation of Ghostscript, Pillow attempts to rasterize the vector file by spawning an external Ghostscript subprocess. Because PostScript is a Turing-complete language, an attacker who successfully routes execution to this interpreter can run arbitrary operations. If the interpreter has known sandbox escape vulnerabilities, this design flaw results in unauthenticated remote code execution on the hosting infrastructure.

The root cause of this vulnerability lies in the architecture of the Pillow image parsing library combined with the lack of input sanitization in WeasyPrint's asset fetching pipeline. In standard operations, Pillow relies on an automatic format detection mechanism implemented inside Image.open(). When an application passes a file-like object or a byte stream to this function, Pillow reads the initial bytes of the payload to identify file signatures, matching them against registered image plugin classes. When an EPS or PS file is supplied, Pillow matches the signature and instantiates PIL.EpsImagePlugin without querying the calling application for authorization.

Because Pillow cannot natively render the complex vector mathematics of PostScript files, it relies on an external rendering engine. The EpsImagePlugin class contains logic that automatically identifies the path to the system's Ghostscript binary (gs) and launches it as an external subprocess using Python's subprocess API. The target PostScript code is passed directly to the interpreter as an argument or standard input stream. This creates an implicit, invisible bridge from a seemingly passive image loading function to a command-line interpreter execution path.

PostScript is not merely a markup syntax; it is a full, Turing-complete language capable of file-system interactions, mathematical evaluations, and execution flow controls. Ghostscript uses sandboxing parameters, specifically the -dSAFER execution flag, to restrict file modifications and operating system calls during rasterization. However, Ghostscript is notoriously complex, and security researchers have historically bypassed this sandbox through numerous memory corruption and logical evaluation flaws, such as CVE-2024-29510. Consequently, by passing user-supplied EPS bytes to Pillow, WeasyPrint exposes the underlying server to any active or zero-day Ghostscript sandbox escape vectors present in the environment.

To understand the exact mechanics of the vulnerability and the subsequent fix, we analyze the implementation within WeasyPrint's core image handling module, located at weasyprint/images.py. Before the patch was applied in version 70.0, WeasyPrint imported standard components from Pillow without overriding default behavior, allowing Pillow to execute system binaries dynamically when an EPS image signature was parsed.

Below is the representation of the vulnerable code path inside weasyprint/images.py contrasted with the applied security patch:

# === VULNERABLE CODE PATH (Pre-v70.0) ===
from PIL import Image, ImageFile, ImageOps
 
# The module initialized generic Pillow parameters but did not restrict
# underlying binary execution configurations.
ImageFile.LOAD_TRUNCATED_IMAGES = True
 
# When an image URI was processed, it was handed straight to Pillow's loader
# which automatically selected EpsImagePlugin if EPS signatures matched:
pillow_image = Image.open(bytestring)

# === PATCHED CODE PATH (v70.0) ===
from PIL import EpsImagePlugin, Image, ImageFile, ImageOps
 
# Don't crash when converting truncated images
ImageFile.LOAD_TRUNCATED_IMAGES = True
 
# [SECURITY FIX] Don't use Ghostscript to render possibly dangerous EPS files.
# By overriding this variable to False, we prevent EpsImagePlugin from
# identifying or executing the external Ghostscript subprocess.
EpsImagePlugin.gs_binary = False

By setting EpsImagePlugin.gs_binary = False globally during module initialization, WeasyPrint completely eliminates the capability of the Pillow library to invoke the external gs command-line utility. If an EPS file is processed, the Pillow library immediately fails to initialize the rendering pipeline and raises an exception. The patch wraps the RasterImage instantiation in a robust exception handling block to prevent these execution failures from crashing the document generation engine, converting the fatal exception into a handled log message instead.

This remediation is highly robust and structurally complete. Since the EpsImagePlugin requires a valid path to gs_binary to generate any subprocess, hardcoding this configuration value to False prevents the subprocess execution path from being reached under any circumstances. It removes the capability entirely, leaving no residual attack paths for variant exploitation of the Ghostscript interpreter via this module.

Exploitation of CVE-2026-106443 requires that the target hosting server has Ghostscript installed and that the application leverages a vulnerable version of WeasyPrint to process user-supplied markup. The attack begins with the generation of an Encapsulated PostScript (EPS) file containing malicious instructions. Since PostScript supports administrative file access operations, an attacker can construct an EPS file that reads or writes local configuration files, or executes administrative utilities on the machine, as demonstrated in the following payload structure:

%!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

Once the payload is formulated, the adversary must force WeasyPrint to fetch and process it. This can be achieved through multiple injection vectors within the submitted HTML. The most direct vector is an <img> tag pointing to the malicious resource. If the target application implements network controls to prevent fetching remote resources, the attacker can bypass this restriction entirely by encoding the payload as a base64 string inside an inline data URI directly in the HTML or CSS stylesheet:

<img src="data:image/eps;base64,JVBTLUFkb2JlLTMuMCBFUFNGLTMuMAolJUJvdW5kaW5nQm94OiAwIDAgMTAwIDEwMAooL3RtcC90ZXN0LW1hcmtlci50eHQpICh3KSBmaWxlCmR1cCAodGVzdF9HSE9TVFNDUklQVF9NQVJLRVJcbikgd3JpdGVzdHJpbmcKY2xvc2VmaWxlCjAuNSBzZXRncmF5IDAgMCAxMDAgMTAwIHJlY3RmaWxsCnNob3dwYWdlCiUlRU9GCg==">

When the backend server triggers the PDF compilation process, WeasyPrint extracts the image asset, routes it to Pillow, and invokes the Ghostscript interpreter. If Ghostscript is vulnerable to a sandbox escape (e.g., CVE-2024-29510), the execution limits are ignored, and the commands are executed directly in the context of the running web application server.

The impact of this vulnerability is critical, representing a direct path to unauthenticated remote code execution on affected application servers. The CVSS 3.1 score is evaluated at 8.8 (High Severity), reflecting the critical combination of a low attack complexity and the complete absence of required user interaction. The attack vector is Network (AV:N), meaning the vulnerability can be exploited remotely across public boundaries without requiring local access to the hosting network.

Upon successful exploitation of the Ghostscript interpreter, the security posture of the application is completely compromised. Since the commands are run under the context of the application server user (e.g., www-data or gunicorn), the attacker gains the ability to read sensitive environmental variables, extract database credentials, manipulate local application source files, or pivot to local container endpoints. In multi-tenant environments, this can lead to cross-tenant data exposure and horizontal privilege escalation.

Currently, the EPSS score for this vulnerability remains low (0.00689, representing the 51.27th percentile), as active exploitation has not yet been widely observed in the wild. Additionally, the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, because PDF generation engines are commonly exposed to public inputs and often run with elevated privileges in internal networks, the actual risk profile for enterprise deployments is substantial.

The primary and most effective remediation path is to upgrade WeasyPrint to version 70.0 or later immediately. This version includes the hardcoded mitigation that disables Pillow's command execution path. In addition to upgrading the Python library, security teams should implement defensive system hardening practices to protect application hosts.

If upgrading WeasyPrint immediately is not possible due to legacy system dependencies, administrators can deploy a programmatic workaround. By modifying the application's entrypoint script (such as wsgi.py, asgi.py, or manage.py) to globally disable Ghostscript parsing inside Pillow prior to initializing any other libraries, you can effectively neutralize the attack surface:

# Programmatic hotfix for legacy WeasyPrint installations
from PIL import EpsImagePlugin
EpsImagePlugin.gs_binary = False

Additionally, host environments should be audited to ensure that Ghostscript is uninstalled if it is not explicitly required for business operations. Containerized workloads (e.g., Docker) should use slim or minimal base images that exclude heavy command-line utilities like Ghostscript. Finally, egress traffic filtering should be enforced on PDF rendering hosts to prevent the application from making unvalidated outbound connections to retrieve malicious EPS files from the public internet.