GHSA-vx6w-vv9f-6gvg - Pillow: EPS load(scale) lets Ghostscript render past the decompression bomb limit
```
============================================================================
EPS load(scale) lets Ghostscript render past the decompression bomb limit
Location: src/PIL/EpsImagePlugin.py:92 in Ghostscript()
Commit: a707c6b21c313880d0771e54965d142dd42358b6
============================================================================
```
When an application opens an untrusted Encapsulated PostScript file and asks Pillow to render it at a larger scale, Pillow has Ghostscript produce an image several times bigger than Pillow's configured size limit allows. The size check runs only after Ghostscript has finished rendering and written the full raw image to a temporary file. An attacker who can upload a file of about 100 bytes makes each such request spend scale² times the Ghostscript rendering work and temporary disk space that the limit is meant to permit. For example, at scale 2 that is a 972 MB temporary file.
The cause is in `Ghostscript()` in `src/PIL/EpsImagePlugin.py`. It multiplies the file-declared size by the caller's `scale` (lines 93-94) and passes the product to `gs` as the `-g` output geometry. It never calls `Image._decompression_bomb_check()` on the scaled size. The only check is the one `Image.open()` ran on the unscaled size, so a file declaring 9000×9000 passes, and `load(scale=2)` then asks Ghostscript for 18000×18000 (3.6× `MAX_IMAGE_PIXELS`). A file declaring 18000×18000 directly would be refused before Ghostscript ever ran. `DecompressionBombError` fires only when Pillow reopens the output file, so Pillow's own in-process allocation stays bounded and there is no memory corruption.
The effect is a constant-factor overshoot rather than an unbounded one, for three reasons:
* The multiplier is an integer chosen by the application, not by the file.
* With the default warning filter, `Image.open()` already lets files up to 2× the limit reach Ghostscript at `scale=1`.
* Any application feeding untrusted files to Ghostscript is already exposed to
MEDIUM
Severity & confidence
Source severitymedium
Platform severitymedium
Confidencemedium
Exploitationunknown
CVSS-
Affected
VendorsPillow
ProductsPillow
Reporting sources (1)
GitHub Security Advisories
Timeline & provenance
Published2026-10-20T20:53:21
Last updated2026-10-21T04:59:36
Ingested2026-10-20T21:09:16
FreshnessNEAR-REAL-TIME
Threat typeadvisory
Recommended action
Review the advisory and upgrade affected packages to the first patched version.
Next steps
- Identify affected systems in your environment.
- Apply the vendor patch or mitigation guidance.
- Review logs for indicators described in the advisory.
- Follow the affected vendor/product to track updates.
Confidence explanation
Reported by a single or secondary source; treat as indicative, verify before acting.
Source type: vendor · Original: GitHub Security Advisories