A buffer growth routine exponentially increases buffer capacity without checking against a maximum decoded size limit. This may allow decompression bombs or oversized stream inputs to exhaust system memory and cause a denial of service.
Rule Explorer
Search the public rule index by CVE, GHSA, CWE, language, framework, author, or rule slug. Filter by language, framework, severity, confidence, license, and validation status.
- Public rules
- 4797
- Downloads
- 10.1M
- Verified
- 4797
- Authors
- 2
Unbounded decompression using `zlib.decompress()` can lead to excessive memory consumption and denial of service (decompression bomb / zip bomb). Use `zlib.decompressobj().decompress(..., max_length)` to enforce an upper bound on the decompressed output size.
Untrusted data is being decompressed directly into memory using a highly suspect function, such as `gzip.decompress()`. Unbounded decompression opens the application to Denial of Service (DoS) via Zip Bomb attacks (CWE-409) where a small, specially crafted compressed payload expands to an unexpectedly large size, exhausting system memory. You should avoid co
Extraction of ZIP archives using `ZipArchive::extractTo()` without validating entry sizes or file count can lead to denial of service via decompression bombs (Zip Bombs).
Unbounded decompression using `gzdecode()`, `gzinflate()`, or `gzuncompress()` can lead to memory exhaustion (Zip Bomb/Data Amplification). An attacker can provide a highly compressed malicious payload to consume all available memory. Provide a safe maximum length as the second argument to prevent this vulnerability.
Unbounded zlib decompression was detected. This can lead to memory exhaustion (decompression bomb) if the compressed data is attacker-controlled. The `zlib.decompress` function does not provide a way to limit the generated output length. Instead, use `zlib.decompressobj()` and call its `decompress()` method with a `max_length` parameter.
One-shot decompression using 'zlib.decompress' on potentially untrusted input materializes the entire decompressed data in memory without enforcing maximum size limits, allowing decompression bombs (CWE-409). Use 'zlib.decompressobj().decompress(..., max_length=...)' to bound the maximum decompressed size.
Unbounded audio decoding detected. An attacker can provide a highly compressed audio file (decompression bomb) that expands into gigabytes of raw PCM data, leading to memory exhaustion and Denial of Service. Limit the maximal amount of frames, samples, or duration decoded, and exit early if limits are exceeded.
Using unbounded decompression functions such as `:zlib.gunzip/1` or `:zlib.uncompress/1` leaves the application vulnerable to Denial of Service (DoS) via decompression bombs (zip bombs). An attacker can send a highly compressed payload that is inflated to a massive size in a single pass, exhausting memory. Avoid single-pass decompression on untrusted data. I
Unbounded decompression of input streams via utility copy methods or transferTo without enforcing a maximum size limit can lead to denial of service via decompression bombs (zip bombs). Read decompressed data incrementally and enforce a strict size threshold.
Unbounded decompression using `zlib` can lead to a Denial of Service (DoS) via memory exhaustion (Zip Bomb) if the compressed data is untrusted. `zlib.decompress` does not allow limiting the output size. Instead, use `zlib.decompressobj().decompress(data, max_length)` with a safe maximum length to restrict the decompressed payload size.
Detected unbounded zlib decompression of a PDF object or stream. Using `zlib.decompress` on untrusted stream attributes (e.g., `_data`, `data`, or `get_data()`) without reinforcing limits makes the application highly vulnerable to decompression bombs (zip bombs), leading to memory exhaustion and Denial of Service (DoS) attacks. Implement bounded decompressio
Variables derived from archive extraction are read directly into memory using `fs.readFile()`. If the archive is a "zip bomb" (highly compressed large files) and lacks size checks, this leads to memory resource exhaustion and Denial of Service (DoS). Replace complete file buffering with bounded streams or explicitly validate the file size before reading it i
When draining an HTTPResponse connection, calling `read()` without explicitly disabling `decode_content` can cause unnecessary decompression of the response body. This leaves the client vulnerable to decompression bomb DoS attacks when processing untrusted HTTP redirects. Explicitly pass `decode_content=False` or the current decoder state to prevent unbounde
Unbounded decompression was detected. Decompressing data without a `max_length` parameter can lead to a Denial of Service (DoS) via "zip bomb" memory exhaustion. Configure a safe `max_length` parameter to limit the size of the decompressed output.
Reading the entirety of a compressed data stream using `ioutil.ReadAll` or `io.ReadAll` can lead to a Denial of Service (DoS) vulnerability due to unbounded memory allocation (e.g., zip bomb attack). Instead, constrain the maximum expected decompressed size by using `io.LimitReader` combined with `ReadAll`, or loop manually over `Read` checks verifying paylo
Directly decompressing files or buffers may lead to a potential Denial of Service (DoS) due to a decompression bomb. Decompression bombs are maliciously compressed files or data that decompresses to extremely large sizes. This can cause the process to run out of memory, or the disk to fill up. To protect against decompression bombs, an [io.LimitReader(...)](