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:

A maximum decompression ratio check
An upper bound on the total output buffer size
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:

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

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

java

// 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

java

// 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

bash

# 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'