Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-21T08:16:37.520Z",
  "pubdate": "2026-09-21T08:16:37.520Z",
  "executiveSummary": "The CompressionFilter component within Apache MINA is susceptible to a resource exhaustion vulnerability caused by improper handling of ZLib-inflated data. The vulnerability arises because the filter does not enforce bounds on the size of inflated data, allowing attackers to supply maliciously crafted compressed payloads that consume excessive system memory upon decompression.\nThis vulnerability is classified as an Uncontrolled Resource Consumption flaw. By exploiting the high compression ratios achievable with ZLib, an attacker can transmit relatively small compressed payloads that expand to several gigabytes in memory. This leads to an out-of-memory (OOM) condition, potentially crashing the application or exhausting server resources, thereby resulting in a Denial of Service (DoS) state.\nThe risk is significant for any application utilizing the CompressionFilter without strict size constraints. The exploitation requires no specific authentication or elevated privileges; it is strictly network-based. Attackers can trigger this condition by sending crafted packets to an endpoint utilizing the vulnerable filter. To mitigate this risk, developers must implement memory-bound constraints and ratio validation during the decompression process.",
  "technicalDetails": "The vulnerability resides in the CompressionFilter class, which manages ZLib-based deflation and inflation for data transmission. The root cause is the absence of a mandatory limit on the memory allocated for the output buffer during the inflation (decompression) process. When the CompressionFilter receives incoming data, it performs an automatic inflation process regardless of the output's final size.\nExploitation leverages the 'Zip Bomb' or 'Decompression Bomb' technique. ZLib compression can achieve ratios exceeding 1:1000 for highly repetitive data. An attacker can craft a relatively small payload that, when processed by the CompressionFilter, attempts to expand into a buffer significantly larger than the available JVM heap space. Because the current implementation lacks an automated check for the resulting size during the inflate operation, the application proceeds to allocate memory based on the compressed input's expansion requirements rather than the system's capacity.\nThe attack flow is straightforward: 1) The attacker identifies a network service using the Apache MINA CompressionFilter. 2) The attacker crafts a compressed payload designed to maximize the expansion ratio. 3) The attacker transmits this payload to the server. 4) The server's CompressionFilter, attempting to inflate the data, performs uncontrolled memory allocation. 5) The application hits the memory limit, causing an OutOfMemoryError and service failure.\nPrior to the implementation of the new control mechanisms, there was no mechanism to distinguish between legitimate high-ratio files and malicious data. The introduction of 'maxDecompressedSize' allows developers to enforce a hard limit on the resulting buffer. Furthermore, the 'maxDecompressRatio' and 'decompressRatioMinSize' parameters allow for nuanced filtering. The 'decompressRatioMinSize' acts as a grace threshold, preventing false positives where legitimate, small-scale files might otherwise trigger a ratio-based security violation. By enforcing these parameters, the filter now validates the size of the uncompressed data against the configured memory constraints before fully expanding the stream into system memory, effectively neutralizing the vector for memory exhaustion."
}