Affected: Homebrew: aider

``` ============================================================================ 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` f…

Affected: CleanStart: apache-superset

Security vulnerability affects the apache-superset package. This issue is resolved in later releases. See references for vulnerability details.

Pillow is a Python imaging library. In versions 2.3.0 through 12.3.0, EPS rendering does not validate the scaled image dimensions before invoking Ghostscript. Applications that process untrusted EPS or PostScript files using an application-selected scale greater than one can incur excessive Ghostscript CPU and temporary disk consumption. In versions with decompression-bomb protection, the scaled output is checked only after Ghostscript has completed rendering, allowing resource consumption beyond the configured pixel limit. The amplification depends on the scale selected by the application, not an attacker-controlled scale value. This issue is fixed in version 13.0.0.

Affected: PyPI: Pillow

``` ============================================================================ 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` f…

mcp: mcp: Denial of Service via session memory exhaustion in streamable HTTP servers vllm: vLLM: Denial of Service via Regular Expression processing vllm: vLLM: Denial of Service via negative token ID input vllm: vLLM: Denial of Service via unbounded P2P KV offloading sessions pillow: pillow: Denial of Service via decompression bomb check bypass in multi-frame images pillow: pillow: Denial of Service via decompression bomb bypass in SPIDER images pillow: pillow: Denial of Service via crafted RLE BMP image pillow: Pillow multi-frame loaders can reuse stale native image storage after mode transitions pillow: pillow: Denial of Service via duplicate page references in PDF files pillow: pillow: Denial of Service via integer overflow in text-width calculation pillow: Pillow: Denial of Service via negative archive member size in TarIO pillow: pillow: Denial of Service via repeated EXIF headers pillow: Pillow: Denial of Service via out-of-bounds read in metafile parser pillow: pillow: Arbitrary code execution via JPEG encoder buffer overflow vllm: vLLM: Denial of Service via unbounded media ingestion aiohttp: aiohttp: Information disclosure via unenforced Secure attribute on shared cookies aiohttp: aiohttp: Denial of Service via missing initial request timeout aiohttp: aiohttp: Denial of Service via Max-Age processing overflow aiohttp: aiohttp: Denial of Service via file descriptor exhaustion in multipart request processing aiohttp: aiohttp: Security control bypass via request schem…

Security update for python-Pillow