CWE-409Base

Improper Handling of Highly Compressed Data (Data Amplification)

Incomplete in the CWE catalog · 166 CVEs mapped

166
CVEs mapped
7.1
Median CVSS
What it is

The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.

Recent examples
8.7cvss
CVE-2026-93471

Unbounded SAML message decompression in esaml allows memory exhaustion

Improper Handling of Highly Compressed Data (Data Amplification) in esaml_binding in dropbox esaml allows an unauthenticated attacker to exhaust server memory and crash the Erlang VM via a crafted compressed SAMLResponse. esaml_binding:decode_response/2 base64-decodes the attacker-supplied SAMLResponse, inflates it with zlib:unzip/1 with no bound on the output, then converts the result to a charlist with binary_to_list/1 before parsing. This runs on the SAML consume (ACS) and single-logout endpoints, which accept unauthenticated requests by design, and it runs before any signature check. A small deflate stream reaches a compression ratio near 1000 to 1, so a request body of tens of kilobytes inflates to hundreds of megabytes and then to several gigabytes of list heap, so a few requests exhaust memory and take the node down. This issue affects esaml: from 0.1.0 onward.

HIGHno explanation yet
—
epss
—none
CVE-2026-96637

CVE-2026-96637 - UNKNOWN Severity Vulnerability

Pillow is a Python imaging library. Prior to 13.0.0, SpiderImageFile.seek() in src/PIL/SpiderImagePlugin.py reparses a later SPIDER stack frame and replaces self._size without rerunning Image._decompression_bomb_check(). A tiny file can use a safe first frame to pass Image.open() and then declare very large dimensions in a later mode F frame. Loading that frame allocates approximately four bytes per attacker-declared pixel and can consume multiple gigabytes of memory. This issue is fixed in version 13.0.0.

no explanation yet
—
epss
6.5cvss
CVE-2026-96636

CVE-2026-96636 - MEDIUM Severity Vulnerability

Pillow is a Python imaging library. Prior to 13.0.0, MpoImageFile.seek() and DcxImageFile.seek() reparse later MPO or DCX frames and replace self._size without rerunning Image._decompression_bomb_check(). A crafted multi-frame image can use a tiny first frame to pass Image.open() and then declare an over-limit later frame. Normal frame iteration through seek(), load(), or ImageSequence.Iterator can decode that frame and commit hundreds of megabytes or more, causing memory-exhaustion denial of service. This issue is fixed in version 13.0.0.

MEDIUMno explanation yet
—
epss
The record
Technical detail
CWE ID
CWE-409
Abstraction
Base
Structure
Simple
Status
Incomplete