| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, The cowboy WebSocket options at line 117 set compress => true, enabling RFC 7692 permessage-deflate negotiation. The handler does not set max_frame_size, so cowboy's default of infinity applies. cowlib's cow_ws:parse_payload/9 calls zlib:inflate/2 on the compressed payload with no output-size limit. An attacker can negotiate permessage-deflate during the WebSocket upgrade and send a frame containing a zlib bomb (e.g. 50 KB → 5 GB). Decompression occurs in the connection process before websocket_handle/2 ever sees the MQTT bytes. An unauthenticated attacker can crash a RabbitMQ node running the Web-MQTT plugin by sending a single highly-compressed WebSocket frame (a few KB on the wire) that inflates to gigabytes in memory. The cowboy WebSocket handler decompresses the entire frame before the MQTT CONNECT packet is processed, so no credentials are required. Preconditions include rabbitmq_web_mqtt plugin enabled (not default, but common for browser clients) Network reachability to port 15675/15676 No authentication required. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. |
| A flaw was found in libsoup's WebSocket implementation when using the permessage-deflate extension. The extension's decompression loop (inflate()) processes data in chunks without enforcing an upper boundary limit on the output buffer size. While libsoup limits the incoming compressed frame size via max_incoming_payload_size, it fails to track or limit memory allocation during decompression. A separate check for decompressed size (max_total_message_size) exists but executes only after inflation is complete, and it is entirely disabled by default for client connections. A remote, unauthenticated attacker can exploit this by sending a small, highly compressed payload (a decompression bomb), causing unbounded memory allocation that triggers an Out-of-Memory (OOM) crash and a Denial of Service (DoS). |
| Vector is a high-performance observability data pipeline. From 0.15.0 until 0.57.0, the logstash source feeds each decompressed frame back into its decoder without limiting nested compression depth. An unauthenticated remote peer that can reach the default 0.0.0.0:5044 listener can send many nested compressed frames, causing recursive decoding that exhausts the worker thread stack and aborts the process. The same nested construction amplifies decompressed input, and process termination can halt log ingestion for every tenant on a shared pipeline. This issue is fixed in version 0.57.0. |
| Netdata is an open source observability tool. Prior to 2.11.0, Netdata's unauthenticated WebSocket server negotiates permessage-deflate before authentication, and src/web/websocket/websocket-compression.c allows websocket_client_decompress_message() to grow decompressed output toward WS_MAX_DECOMPRESSED_SIZE without enforcing a compressed-to-decompressed ratio. Small highly compressed frames can therefore cause large server-side allocations, and repeated concurrent connections can exhaust memory and terminate monitoring. This vulnerability is fixed in 2.11.0. |
| Improper handling of highly compressed data (data amplification) in Checkmk <2.5.0p14, <2.4.0p37, <2.3.0p51 and 2.2.0 (EOL) allows an attacker who controls a host registered for push mode to exhaust the memory of the agent receiver by sending a small zlib compressed payload that decompresses to an arbitrary size. |
| Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. From 8.0.0 until 8.0.6, the HTTP/1 parser limits decompression work per transaction but does not limit how many small brotli compression bombs a single flow can submit. With response-body-decompress-layer-limit enabled, repeated compressed responses make the decompression paths in rust/htp perform expensive work for every transaction, degrading packet processing and potentially causing loss of monitoring visibility or denial of service. This issue is fixed in version 8.0.6. |
| The CompressionFilter class uses ZLib to deflate and inflate data sent and received. When we inflate incoming data, the filter does not control the resulting size, and create a buffer no matter what.
Some compressed data may have a compression ration greater than 1 thousand, leading to an exhaustion of the application memory, as we don't control the deflated size.
The fix adds such a control by allowing the application developer to provide a fixed size limit, which when reached throws an exception. It also allows the user to provide a compression ratio that should not be exceeded, protected the application from small inflated files that inflate in gigantic files, but with a grace limit for the resulting size (1Mb) to avoid false positive (like a very small file inflating with a high ratio, but resulting with a acceptable size, like a few thousands bytes)
For application using this feature, it is highly recommended to create the CompressionFilter and to pass the maximum limit as a forth constructor parameter, maxDecompressedSize:
public CompressionFilter(final boolean compressInbound, final boolean compressOutbound, final int compressionLevel, final int maxDecompressedSize)Optionally one can also provide a maxDecompressRatio fifth parameter, and a decompressRatioMinSize sixth parameter to allow small inflated files with a high compression ratio to still be accepted.
Here are the additional constructor:
public CompressionFilter(final boolean compressInbound, final boolean compressOutbound,
final int compressionLevel, final int maxDecompressedSize,
final long maxDecompressRatio, final long decompressRatioMinSize)
Also note that a fluent API has been added to spare the users the pain to call a constructor with that many parameters:
CompressionFilter compressionFilter = new CompressionFilter()
.setCompressionLevel(Zlib.COMPRESSION_MAX)
.setMaxDecompressedSize(1_000_000)
.setMaxDecompressRatio(100).
.setDecompressRatioMinSize(100_000);
Applications using Apache MINA are advised to upgrade and configure their CompressionFilter instance. |
| Apache NiFi 2.11.0 disabled support for gzip-encoded HTTP requests for the application REST API and rejected requests that included the standard Content-Encoding header indicating gzip encoding. The framework enforcement filter did not check multiple instances of the Content-Encoding header and did not reject non-standard identifiers for gzip encoding, allowing a malicious client to send crafted requests that could consume excessive amounts of memory. Upgrading to Apache NiFi 2.12.0 is the recommended mitigation, which disables decompression of gzip-encoded HTTP requests regardless of header number or encoding identifiers. |
| The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, automatic response decompression on the HTTP/1.1 path uses ChannelManager.newHttpContentDecompressor() to install Http1ContentDecompressor without a cumulative output-size limit. A hostile or compromised server, or an attacker who can alter a response in transit, can send a small gzip, deflate, or snappy response that expands across chunks until the client exhausts its heap and raises OutOfMemoryError; brotli and zstd are also affected when their optional codecs are present. In versions 3.0.8 through 3.0.10, the HTTP/2 decompressor is also unbounded, so switching protocols does not mitigate the issue on those releases. A limit applied to each decode call is insufficient because the response can be delivered as many small chunks, so the fixed implementation tracks total decompressed bytes for the whole response. This issue is fixed in versions 2.16.1 and 3.0.12. |
| Autobahn Python is a WebSocket and WAMP implementation for Python that supports Twisted and asyncio. Prior to 26.7.1, WebSocket endpoints that accept permessage-deflate and rely on maxMessagePayloadSize enforce that limit against the compressed frame length before inflation but do not recheck the decompressed message size before delivery. A remote unauthenticated client can send a valid compressed frame below the configured wire-size limit that expands beyond the application message limit, causing oversized data to be allocated, joined, validated, and passed to application callbacks. This can create resource-exhaustion pressure, but the advisory does not establish confidentiality or integrity impact. This issue is fixed in version 26.7.1. |
| adm-zip versions 0.5.14 through 0.6.0 fail to apply zlib decompression output limits when ZIP entries declare zero uncompressed size. Attackers can craft malicious ZIP archives with highly compressible entries declaring zero size to exhaust memory and cause denial of service. |
| fluent-plugin-s3 is an Amazon S3 input and output plugin for Fluentd. From 0.7.0 to 1.8.4, the in_s3 input plugin reads the entire decompressed payload of gzip, lzma2, and lzop objects into memory without enforcing a decompression_size_limit. An attacker with permission to upload objects to the monitored S3 bucket can provide a highly compressed object that expands excessively when Fluentd processes it. The resulting memory exhaustion can cause the operating system to terminate the Fluentd process and disrupt all log collection on the affected node. This issue is fixed in version 1.8.5. |
| fluent-plugin-opentelemetry is a Fluentd input and output plugin for forwarding OpenTelemetry Protocol data. Prior to 0.5.3, the in_opentelemetry HTTP input read the entire incoming request body and decompressed payloads into memory without enforcing maximum size thresholds. When an OpenTelemetry ingestion endpoint was exposed to an untrusted network, an attacker could send an excessively large request or a highly compressed payload that expanded in memory. The resulting memory exhaustion could cause the operating system to terminate the Fluentd process, disrupting all log collection and forwarding on the affected node. This issue is fixed in version 0.5.3. |
| HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.12, SHCParser in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java can consume attacker-controlled Smart Health Card JWT content whose header contains zip: "DEF" and whose small raw-DEFLATE payload expands to a very large value. SHCParser.decodeJWT() passes the decoded payload to SHCParser.inflate(), which accumulates all decompressed bytes in a ByteArrayOutputStream without an output-size limit before JSON parsing, and SHCParser.decompress() contains the same unbounded pattern. An application or validator service that accepts attacker-supplied SHC content can therefore suffer excessive heap allocation, severe garbage-collection pressure, request failure, process instability, or process termination. This issue is fixed in version 6.9.12. |
| Wazuh 4.4.0 before 4.14.7 contains a denial of service vulnerability in the fdecompress_files() function within cluster.py that allows authenticated cluster peers to exhaust memory by supplying a malicious synchronization archive without decompressed size limits. Attackers holding a valid cluster Fernet key can upload a small, highly compressed zip bomb archive that forces wazuh-clusterd on the master node to decompress the full payload into memory, causing memory exhaustion and service disruption. |
| In JetBrains YouTrack before 2026.2.18177 doS attack was possible via a decompression bomb in the import endpoint |
| Publishing limits the compressed size of a VSIX (ovsx.publishing.max-content-size, 512 MB by default) but nothing limited how large an entry becomes when opened.
On the first request to /vscode/unpkg/{namespace}/{extension}/{version}/{path}, WebResourceService opened the entry with ZipFile.getInputStream() and passed the decompressed stream to Files.copy(), which ran to the end of the stream without counting bytes written. The result was cached under java.io.tmpdir, and that cache evicted by entry count (150), not by size, so it placed no bound on disk usage.
A publisher with access only to their own namespace could therefore upload a small, highly compressible VSIX and cause the server to write far larger files to the temp filesystem — repeating with different files or versions, since a repeat request is served from the cache.
Impact observed: the temp filesystem filled; requests for files not already cached returned 500 with No space left on device; a failed extraction left a partial cache file that blocked later attempts at that path; publishing failed with Failed to read extension file. Metadata and already-cached files kept working, and the server did not stop.
Triggering the extraction needs no authentication — only the upload does. |
| http4k is a functional toolkit for Kotlin HTTP applications. Prior to 4.51.0.0, 5.42.0.0, and 6.49.0.0, ServerFilters.GZip, RequestFilters.GunZip, and the underlying Gzip request-body decompression functions impose no limit on decompressed size. An unauthenticated client can send a small gzip-encoded request body that expands to gigabytes, exhausting the JVM heap and denying service to other clients. The fix uses SizeLimitedInputStream to enforce a default 10 MiB limit, causes ServerFilters.GZip and RequestFilters.GunZip to return 413 Request Entity Too Large, and causes other decompression paths to throw SizeLimitExceededException. This issue is fixed in versions 4.51.0.0, 5.42.0.0, and 6.49.0.0. |
| vLLM versions before 0.28.0 fail to validate audio sample rate headers in the transcription endpoint, allowing authenticated clients to bypass duration checks. Attackers can submit forged FLAC headers with inflated sample rates to trigger excessive memory allocation and crash the API server process affecting all tenants. |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Handling of Highly Compressed Data (Data Amplification) vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to denial of service. |
