Evidence used
- No CISA KEV confirmation is currently recorded.
- The selected CVSS metric records a network-reachable, unauthenticated path with no user interaction.
- EPSS is 0.49% for the current model date.
BlackTreeCVE IntelligenceApache Software Foundation · Apache MINA
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
Debian, ubuntu findings are scoped to the named distribution, release and source package. An absent finding does not mean a package is unaffected.
A published vendor fix does not prove that a matching update is enabled and installable on a particular asset. Confirm the local package candidate before scheduling remediation.
| Distribution release | Source package | Vendor state | Fixed version | Evidence |
|---|---|---|---|---|
| Debian trixietrixie · source | mina2 | Affected, no fix publishedDebian currently tracks this release as open. | Not published in this feed | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian bookwormbookworm · source | mina | Affected, no fix publishedDebian currently tracks this release as open. | Not published in this feed | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian bookwormbookworm · source | mina2 | Affected, no fix publishedDebian currently tracks this release as open. | Not published in this feed | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian forkyforky · source | mina2 | Vendor fix publishedDebian records a fixed source-package version for this release. | 2.2.9-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Debian sidsid · source | mina2 | Vendor fix publishedDebian records a fixed source-package version for this release. | 2.2.9-1 | Debian Security Tracker ↗Source updated 6 Oct 2026 |
| Ubuntu 24.04 LTSnoble · esm-apps | mina2 | Under evaluationCanonical reports that the package might be affected and still needs evaluation or fixing. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
| Ubuntu 24.04 LTSnoble · standard archive | mina | Under evaluationCanonical reports that the package might be affected and still needs evaluation or fixing. | Not published in this feed | Canonical Ubuntu Security ↗Source updated 5 Oct 2026 |
Structured product status and remediation from the issuing vendor. Product-state explanations are always visible; large lists can be searched or downloaded.
The vendor explicitly identifies these products as affected by this CVE.
High technical severity; prioritise exposed affected systems while verifying vendor guidance.
Fix not verifiedThe 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.
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.
The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
An attacker operating through a network path may attempt exploitation without authentication or user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
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.
The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
An attacker operating through a network path may attempt exploitation without authentication or user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-409: Improper Handling of Highly Compressed Data (Data Amplification). The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 21 Sept 2026 · Last source change 21 Sept 2026, 18:09 UTC · CWE-409 · Improper Handling of Highly Compressed Data (Data Amplification)
Core structured fields are present and their contributing authorities are shown above.