Skip to content

← Public intelligence

Maven package

io.netty:netty-codec-compression

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 8.7MavenPublished

    Netty: [Bzip2Decoder] Infinite Loop in RLE State Machine Leads to Event-Loop Thread Hang

    CVE-2026-59901 · GHSA-558v-64gr-wgg4

    Affected
    • Maven io.netty:netty-codec-compression >= 4.2.0.Final, < 4.2.16.Final
    Fixed in
    4.2.16.Final· Vendor fix available
    Issue
    The Bzip2Decoder handler in Netty's compression codec pipeline is vulnerable to a denial-of-service attack through a malformed bzip2 stream that permanently captures the event-loop thread in an infinite loop. The vulnerability exists in the run-length encoding (RLE) state machine within [Bzip2BlockDecompressor.read()]

    Recommended action: Upgrade to 4.2.16.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 7.5MavenPublished

    Netty Lz4FrameDecoder is vulnerable to resource exhaustion

    CVE-2026-42583 · GHSA-mj4r-2hfc-f8p6

    Affected
    • Maven io.netty:netty-codec-compression <= 4.2.12.Final
    Fixed in
    4.2.13.Final· Vendor fix available
    Issue
    Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. Details io.netty.handler.codec.compression.Lz4FrameDecoder#decode Header fields are trusted for sizing. On the compressed path, after readableBytes = compressedLength, the decoder does ctx.alloc().buffer(decompressedLength, decompressedLength) then decompresses. PoC The test below demonstrates how an attacker sending 22 bytes will force the server to allocate 32MB Impact Untrusted senders without per-channel / aggregate limits can stress memory with many small requests.

    Recommended action: Upgrade to 4.2.13.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  3. Medium, CVSS 6.9MavenPublished

    Netty's decoders vulnerable to DoS via zip bomb style attack

    CVE-2025-58057 · GHSA-3p8m-j85q-pgmj

    Affected
    • Maven io.netty:netty-codec-compression >= 4.2.0.Alpha1, < 4.2.5.Final
    Fixed in
    4.2.5.Final· Vendor fix available
    Issue
    With specially crafted input, BrotliDecoder and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. Details BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb. Tested on 4.1.118, but there were no changes to the decoder since. PoC Run this test case with -Xmx1G: Error: Impact DoS for anyone using BrotliDecoder on untrusted input.

    Recommended action: Upgrade to 4.2.5.Final or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →