CVE-2026-47321: Apache MINA: Unbounded Decompression Amplification DoS in Zlib.inflate
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.COMPRESSIONMAX)
.setMaxDecompressedSize(1000000)
.setMaxDecompressRatio(100).
.setDecompressRatioMinSize(100000);
Applications using Apache MINA are advised to upgrade and configure their CompressionFilter instance.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
When constructing CompressionFilter (using the provided fluent/constructor options), set maxDecompressedSize to 1_000_000 to enforce a fixed maximum decompressed size limit (throws an exception when reached).
Apache MINA CompressionFilter maxDecompressedSize = 1000000 - Configuration
Set the CompressionFilter maxDecompressRatio to 100 to prevent decompression ratio exhaustion scenarios.
Apache MINA CompressionFilter maxDecompressRatio = 100 - Configuration
Set decompressRatioMinSize to 100_000 to allow small inflated files with a high compression ratio to still be accepted.
Apache MINA CompressionFilter decompressRatioMinSize = 100000 - Configuration
Configure CompressionFilter to use Zlib.COMPRESSION_MAX (setCompressionLevel(Zlib.COMPRESSION_MAX)).
Apache MINA CompressionFilter compressionLevel = Zlib.COMPRESSION_MAX
Event History
Frequently Asked Questions
What deployments are exposed to this denial-of-service condition?
Applications using Apache MINA's CompressionFilter to inflate incoming compressed data are exposed. The issue arises because incoming data can be decompressed without a limit on the resulting buffer size.
What does an attacker need to exploit this issue?
An attacker needs to send compressed input that expands to a very large size when inflated. No privileges or user interaction are required according to the supplied vector.
How can the risk be reduced if the application uses CompressionFilter?
Create the CompressionFilter with a maximum decompressed-size limit using the fourth constructor parameter, maxDecompressedSize. The fix also supports a maximum compression-ratio control, with a 1 MB grace limit for small resulting files.