Description

WeasyPrint helps web developers to create PDF documents. Prior to 70.0, the image-loading path in weasyprint/images.py passes fetched image bytes from HTML img URLs, CSS image values, SVG image references, and data URIs to Pillow's generic image dispatcher without excluding EPS or PostScript formats. On hosts with Ghostscript installed, Pillow EpsImagePlugin invokes the interpreter for attacker-controlled PostScript, which can produce interpreter-permitted effects and can lead to remote code execution when the installed Ghostscript version has a usable sandbox bypass. Hosts without Ghostscript do not reach this rasterization path. This issue is fixed in version 70.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-10-06T19:18:13.327Z",
  "pubdate": "2026-10-06T19:18:13.327Z",
  "executiveSummary": "WeasyPrint versions prior to 70.0 contain a critical vulnerability in the image-loading process that allows for Remote Code Execution (RCE).\nThe vulnerability stems from the improper handling of image file formats, specifically the failure to restrict the processing of EPS (Encapsulated PostScript) or PostScript files within the Pillow image processing library.\nWhen a host environment has Ghostscript installed, the Pillow EpsImagePlugin automatically invokes the Ghostscript interpreter to rasterize these files.\nAn attacker can leverage this behavior by providing a malicious image source—via HTML img tags, CSS properties, or data URIs—containing crafted PostScript code.\nIf the installed version of Ghostscript contains a sandbox bypass, the attacker can execute arbitrary commands with the privileges of the WeasyPrint process.\nThe risk is significant for server-side applications that process untrusted HTML or CSS content, as it allows for unauthorized system access and potential compromise of the host infrastructure.\nExploitation is contingent upon the presence of Ghostscript on the host system; systems without Ghostscript are not susceptible to this specific rasterization-based attack vector.",
  "technicalDetails": "The root cause of the vulnerability resides in the weasyprint/images.py module, which performs image fetching and dispatching for various assets referenced in HTML and CSS.\nPrior to version 70.0, the image-loading path passes fetched byte streams directly to the Pillow generic image dispatcher without applying an allow-list or filter to exclude dangerous file formats.\nSpecifically, the dispatcher allows the processing of EPS and PostScript files. When Pillow encounters an EPS file, it utilizes the EpsImagePlugin, which acts as a wrapper for Ghostscript to handle the rendering of the PostScript vector data into a bitmap format.\nThe attack flow initiates when an attacker embeds a malicious URI (pointing to a remote PostScript file) or a base64-encoded data URI in an HTML document processed by WeasyPrint.\nUpon processing, the application fetches the malicious bytes and passes them to the Pillow dispatcher. The EpsImagePlugin then invokes the local Ghostscript binary to interpret the contents.\nThe security impact is realized when the Ghostscript environment is susceptible to sandbox bypass vulnerabilities. Because Ghostscript is designed to execute code to render graphics, a malicious PostScript payload can instruct the interpreter to escape its restricted environment.\nBy bypassing the Ghostscript sandbox, the attacker executes arbitrary shell commands or code within the context of the user running the WeasyPrint process.\nThe vulnerability does not require authentication, as it is triggered by the application's standard rendering workflow of untrusted input. The exposure is network-based to the extent that the input HTML/CSS is sourced from an attacker-controlled origin.\nPost-exploitation impact includes the full compromise of the application container or host server, data exfiltration, and lateral movement within the network.\nThe vulnerability is explicitly remediated in WeasyPrint 70.0, which introduces changes to the image-loading pipeline to explicitly exclude EPS and PostScript formats, effectively disabling the reliance on the vulnerable EpsImagePlugin for untrusted image streams."
}