Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

WeasyPrint: EPS images reach the Ghostscript interpreter resulting in RCEGHSA-r543-q48m-4c9j

HIGHFix: Kozea/WeasyPrint@39cd37c

GHSA-r543-q48m-4c9j is a high-severity (CVSS 8.8) Improper Input Validation vulnerability in weasyprint. A fix is available for weasyprint — see the affected versions and patch details below.

Also known asCVE-2026-106443PYSEC-2026-4311
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-r543-q48m-4c9j.

EPSS Exploitation Probability

via FIRST.org ↗
0.7%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs52th percentile — riskier than 52% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-r543-q48m-4c9j by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍weasyprint

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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.
  2. Embed the payload in a data:image/x-eps;base64,... URI inside an <img> element and render the document with WeasyPrint. The run requires no shell, network, reverse shell, or deployment endpoint.
  3. Observe the outcome: record the Ghostscript version, the render return code, the generated PDF size, and the private marker file contents. On Ghostscript 10.05.1 this was constrained to the bounded file write above.
  4. To confirm the full RCE chain, a down-rev Ghostscript 10.03.0 was invoked directly with the CVE-2024-29510 payload while a netcat listener ran on 127.0.0.1:4444. The Ghostscript subprocess connected back and dropped into an interactive shell within a 30-second window:

$ nc -lvnp 4444 127.0.0.1 & Ncat: Version 7.94 ( https://nmap.org/ncat ) Ncat: Listening on 127.0.0.1:4444

$ gs -dSAFER -dBATCH -dNOPAUSE -dPARANOIDSAFER -sDEVICE=ppmraw
-sOutputFile=/dev/null - < cve-2024-29510_payload.eps ... Ncat: Connection from 127.0.0.1:51884. bash: cannot set terminal process group (261755): Inappropriate ioctl for device bash: no job control in this shell tester@host:~$

  1. A host without Ghostscript installed does not reach the EPS rasterization path.

Impact

This is a remote code execution vulnerability (via untrusted-input-to-external-interpreter dispatch).

  • Rendering untrusted EPS through WeasyPrint on a host with Ghostscript installed executes attacker-controlled PostScript. On Ghostscript 10.05.1 the effded file write.
  • On a host running a Ghostscript version with a known -dSAFER bypass, the same input path yields full remote code execution — demonstrated with CVE-2024.03.0, which is still shipped in many LTS and end-of-life branches.
  • The unconditional defect in WeasyPrint is the missing image-format allowlist, which is what makes the interpreter reachable from untrusted input.

Who is impacted:

Any deployment that renders untrusted or partially-untrusted HTML/CSS/SVG through WeasyPrint on a host where Ghostscript is installed along combination on general-purpose document-rendering servers.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIweasyprintall versions70.0pip install --upgrade 'weasyprint==70.0'

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for weasyprint, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update weasyprint to 70.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r543-q48m-4c9j is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

An IMPORTANT severity flaw was found in WeasyPrint, a Python library for converting HTML and CSS documents to PDF that is shipped in Red Hat Ansible Automation Platform 2.5 via the automation-dashboard container image. When WeasyPrint renders documents with external image references (HTML img URLs, CSS image values,…

Workaround published by Red Hat
This flaw can be mitigated by removing Ghostscript from hosts where WeasyPrint renders untrusted documents: the vulnerable code path requires Pillow's EpsImagePlugin to invoke the Ghostscript interpreter, and hosts without Ghostscript installed never reach the PostScript rasterization path. Exposure can also be reduced by restricting WeasyPrint to render only trusted documents, or by blocking external image references (img URLs, CSS image values, SVG image references, and data URIs) from untrusted sources. For full remediation, upgrade to a version of WeasyPrint that contains the upstream fix.
Source: Red Hat security advisory for GHSA-r543-q48m-4c9j (CC BY 4.0)

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is GHSA-r543-q48m-4c9j in your dependencies?

Find it across PyPI, including transitive dependencies.

WeasyPrint: EPS images reach the Ghostscript interpreter…