Every CVE Search/ Get API key

CVE-2026-47321

Apache MINA: Unbounded Decompression Amplification DoS in Zlib.inflate

7.5 HighFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
High

Exploit likelihood

0.49%Up 0.2 points since Sep 21, 2026
90%50%10%1%

What each source reports

CVE List Score used 7.5

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.COMPRESSION_MAX)

  .setMaxDecompressedSize(1_000_000)

  .setMaxDecompressRatio(100).

  .setDecompressRatioMinSize(100_000); 

Applications using Apache MINA are advised to upgrade and configure their CompressionFilter instance.

Record
CVE-2026-47321
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-409, CWE-789
Updated
2026-11-02
EUVDEUVD-2026-83858 7.5

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.

Record
EUVD-2026-83858
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
GitHub AdvisoriesGHSA-3c8x-fp36-75xv 7.5

The CompressionFilter class uses ZLib to deflate and inflate data sent and received. When we...

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.

Record
GHSA-3c8x-fp36-75xv
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-409
Updated
2026-11-02
NVD 7.5

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.

Record
CVE-2026-47321
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-409, CWE-789
Updated
2026-11-02
OSVDEBIAN-CVE-2026-47321 7.5

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.

Record
DEBIAN-CVE-2026-47321
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
OSVRHLW-2026-2cb9a31c02a7f38b 7.5

Lightwell Security Advisory: mina-filter-compression 2.2.5.rhlw-00008

Red Hat Lightwell has released org.apache.mina:mina-filter-compression 2.2.5.rhlw-00008 with a backported security fix.

CVE-2026-47321: 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.

This patched artifact is a drop-in replacement for org.apache.mina:mina-filter-compression 2.2.5 from Maven Central.

Record
RHLW-2026-2cb9a31c02a7f38b
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
OSVUBUNTU-CVE-2026-47321 7.5

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.

Record
UBUNTU-CVE-2026-47321
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
mina
Debian:12
All versions, plus listed versions
1.1.7.dfsg-131.1.7.dfsg-14
None known
mina2
Debian:12
All versions, plus listed versions
2.2.1-32.2.1-42.2.9-1
None known
mina2
Debian:13
All versions, plus listed versions
2.2.1-42.2.9-1
None known
mina2
Debian:14
before 2.2.9-1, plus listed versions
2.2.1-4
2.2.9-1
org.apache.mina:mina-filter-compression
Red Hat Lightwell:Maven
before 2.2.5.rhlw-00008, plus listed versions
1.0.01.0.11.0.101.0.21.0.3
Show 45 moreShow less
1.0.41.0.51.0.61.0.71.0.81.0.91.1.01.1.11.1.21.1.31.1.41.1.51.1.61.1.72.0.02.0.0-M12.0.0-M22.0.0-M32.0.0-M42.0.0-M52.0.0-M62.0.0-RC12.0.12.0.102.0.112.0.122.0.132.0.142.0.152.0.162.0.172.0.182.0.192.0.22.0.202.0.212.0.222.0.232.0.242.0.252.0.262.0.272.0.282.0.292.0.3
2.2.5.rhlw-00008
mina
Ubuntu:16.04:LTS
All versions, plus listed versions
1.1.7.dfsg-11
None known
mina2
Ubuntu:16.04:LTS
All versions, plus listed versions
2.0.7+dfsg-22.0.9-12.0.9-2
None known
mina
Ubuntu:18.04:LTS
All versions, plus listed versions
1.1.7.dfsg-111.1.7.dfsg-12
None known
mina2
Ubuntu:18.04:LTS
All versions, plus listed versions
2.0.16-2
None known
mina
Ubuntu:20.04:LTS
All versions, plus listed versions
1.1.7.dfsg-13
None known
Show 8 moreShow less
Affected packages
PackageAffectedFixed
mina2
Ubuntu:20.04:LTS
All versions, plus listed versions
2.0.19-2
None known
mina
Ubuntu:22.04:LTS
All versions, plus listed versions
1.1.7.dfsg-13
None known
mina2
Ubuntu:Pro:22.04:LTS
All versions, plus listed versions
2.1.4-22.1.5-12.1.5-1ubuntu0.1~esm1
None known
mina
Ubuntu:24.04:LTS
All versions, plus listed versions
1.1.7.dfsg-131.1.7.dfsg-13ubuntu1
None known
mina2
Ubuntu:Pro:24.04:LTS
All versions, plus listed versions
2.2.1-32.2.1-3ubuntu0.1~esm1
None known
mina2
Ubuntu:25.10
All versions, plus listed versions
2.2.1-32.2.1-4
None known
mina2
Ubuntu:26.10
All versions, plus listed versions
2.2.1-42.2.1-4ubuntu12.2.9-1
None known
mina2
Ubuntu:Pro:26.04:LTS
All versions, plus listed versions
2.2.1-42.2.1-4ubuntu0.1~esm1
None known

History

History
RecordedChangedSources
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-47321 is a high vulnerability (CVSS 7.5) in Apache Software Foundation Mina, published September 21, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.49%, the 42nd percentile. Fixed in mina2 2.2.9-1.

References

This page doesn't list everything

Left out here: 30 versions. The JSON record has them.

MoveEnter Open