CVE-2025-58057: Netty BrotliDecoder DoS Vulnerability

CVE-2025-58057 Overview

CVE-2025-58057 is a denial of service vulnerability in the Netty asynchronous event-driven network application framework. The vulnerability affects the BrotliDecoder and other decompression decoders in the netty-codec-compression and netty-codec components. When processing specially crafted input, these decoders allocate an unbounded number of reachable byte buffers, leading to memory exhaustion and denial of service conditions.

The core issue lies in the BrotliDecoder.decompress method, which has no limit on how often it calls the pull function, decompressing data in 64KB chunks. These buffers accumulate in an output list and remain reachable until an OutOfMemory (OOM) error occurs, effectively crashing the application.

Critical Impact

Applications using Netty's compression codecs are vulnerable to resource exhaustion attacks where malicious actors can trigger out-of-memory conditions by sending specially crafted compressed data, resulting in denial of service.

Affected Products

• Netty netty-codec-compression versions 4.1.124.Final and below
• Netty netty-codec versions 4.2.4.Final and below
• Applications using affected Netty decompression handlers

Discovery Timeline

• September 4, 2025 - CVE-2025-58057 published to NVD
• September 8, 2025 - Last updated in NVD database

Technical Details for CVE-2025-58057

Vulnerability Analysis

This vulnerability is classified as CWE-409 (Improper Handling of Highly Compressed Data), commonly known as a "decompression bomb" or "zip bomb" vulnerability. The issue stems from improper resource management in Netty's decompression handlers.

The BrotliDecoder component processes compressed data by repeatedly calling the pull method to decompress 64KB chunks. However, there is no mechanism to limit the total number of decompression iterations or the aggregate size of allocated buffers. An attacker can craft a small compressed payload that expands to an extremely large size, causing the decoder to allocate memory continuously until the JVM runs out of heap space.

This network-accessible vulnerability requires no authentication and can be exploited remotely by any client capable of sending compressed data to the vulnerable service.

Root Cause

The root cause is the absence of decompression limits in the BrotliDecoder and similar decompression decoders. The decompress method lacks:

1. A maximum decompression ratio check
2. An upper bound on the total output buffer size
3. Limits on the number of decompression iterations

The decompressed buffers are stored in an output list and remain reachable by the garbage collector, preventing memory reclamation until the OOM condition is reached.

Attack Vector

The attack vector is network-based, allowing remote exploitation without authentication. An attacker can exploit this vulnerability by:

1. Establishing a connection to a Netty-based service that uses affected compression handlers
2. Sending a small, highly compressed payload (decompression bomb)
3. Triggering the unbounded decompression loop, causing rapid memory allocation
4. Exhausting the server's available memory, leading to service unavailability

The following code snippets from the security patch demonstrate the fix implementation:

// From BrotliDecoder.java - Removing direct ByteBufAllocator usage
 
import com.aayushatharva.brotli4j.decoder.DecoderJNI;
import io.netty.buffer.ByteBuf;
-import io.netty.buffer.ByteBufAllocator;
import io.netty.channel.ChannelHandlerContext;
import io.netty.handler.codec.ByteToMessageDecoder;
import io.netty.util.internal.ObjectUtil;

Source: GitHub Commit

// From JZlibDecoder.java - Adding read control flag
 
    private final Inflater z = new Inflater();
    private byte[] dictionary;
+    private boolean needsRead;
    private volatile boolean finished;

    /**

Source: GitHub Commit

Detection Methods for CVE-2025-58057

Indicators of Compromise

• Abnormal memory consumption patterns in Java heap, particularly rapid growth during request processing
• OutOfMemoryError exceptions in application logs related to Netty handlers
• Unusual network traffic containing small payloads with high compression ratios
• Service crashes or restarts coinciding with specific client connections

Detection Strategies

• Monitor JVM heap usage metrics for sudden spikes during network I/O operations
• Implement application-level logging for decompression operations to track buffer allocation sizes
• Configure alerts for java.lang.OutOfMemoryError events in log aggregation systems
• Deploy network intrusion detection rules to identify known decompression bomb patterns

Monitoring Recommendations

• Set up JMX monitoring for Netty's buffer pool metrics and memory allocation rates
• Implement circuit breakers to limit decompression operations per connection
• Configure heap dump generation on OOM events for forensic analysis
• Monitor connection-level statistics for clients sending abnormally small but resource-intensive requests

How to Mitigate CVE-2025-58057

Immediate Actions Required

• Upgrade netty-codec to version 4.1.125.Final or later
• Upgrade netty-codec-compression to version 4.2.5.Final or later
• Review and update all Maven/Gradle dependencies that transitively include Netty
• Test updated dependencies in staging environments before production deployment

Patch Information

The Netty project has released fixed versions that address this vulnerability:

• netty-codec: Version 4.1.125.Final (fixes versions 4.1.124.Final and below)
• netty-codec-compression: Version 4.2.5.Final (fixes versions 4.2.4.Final and below)

The fix introduces proper read control mechanisms in the decompression handlers to prevent unbounded buffer allocation. For detailed patch information, refer to the GitHub Security Advisory and the security patch commit.

Workarounds

• Implement application-level limits on decompressed data size before passing to Netty decoders
• Disable Brotli decompression if not required by your application
• Deploy a reverse proxy or WAF that can inspect and limit compressed payload ratios
• Configure JVM memory limits to prevent complete system exhaustion during attacks

# Maven dependency update example
# Update pom.xml to use fixed Netty versions
mvn versions:use-latest-versions -Dincludes=io.netty:netty-codec*

# Gradle dependency update
# In build.gradle, force the patched version
implementation 'io.netty:netty-codec:4.1.125.Final'
implementation 'io.netty:netty-codec-compression:4.2.5.Final'