CVE-2024-29025: Netty HttpPostRequestDecoder DoS Flaw

CVE-2024-29025 Overview

CVE-2024-29025 is a Resource Exhaustion vulnerability in Netty, an asynchronous event-driven network application framework widely used for developing high-performance protocol servers and clients. The vulnerability exists in the HttpPostRequestDecoder component, which can be manipulated to accumulate unbounded data in memory, potentially leading to denial of service conditions.

The flaw allows attackers to exploit the lack of limits on form fields processed by the decoder. An attacker can send a chunked POST request containing numerous small fields that accumulate in the bodyListHttpData list. Additionally, the decoder stores bytes in the undecodedChunk buffer until a field can be decoded, and this buffer can grow without limits, enabling memory exhaustion attacks.

Critical Impact

Applications using Netty's HttpPostRequestDecoder without additional safeguards are vulnerable to memory exhaustion attacks, potentially causing service unavailability through unbounded data accumulation.

Affected Products

• Netty versions prior to 4.1.108.Final
• Debian Linux 10.0 (with affected Netty packages)
• Any application or service incorporating vulnerable Netty versions

Discovery Timeline

• 2024-03-25 - CVE-2024-29025 published to NVD
• 2025-09-19 - Last updated in NVD database

Technical Details for CVE-2024-29025

Vulnerability Analysis

This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The HttpPostRequestDecoder in Netty processes HTTP POST multipart/form-data requests but fails to enforce limits on the number of form fields or the total size of accumulated data.

When processing chunked POST requests, the decoder accumulates field data in two critical locations: the bodyListHttpData list for decoded fields and the undecodedChunk buffer for pending data. Neither structure has enforced limits, allowing an attacker to craft requests that cause unbounded memory consumption.

While Netty does provide functionality to store items on disk when configured, this mitigation does not address the core issue—there are no limits to the number of fields a form can contain. This design flaw enables attackers to send malicious requests consisting of many small fields that bypass disk-based mitigations while still exhausting memory resources.

Root Cause

The root cause lies in the absence of resource allocation limits within the HttpPostRequestDecoder implementation. The decoder was designed without bounds checking for:

1. The number of fields that can be accumulated in bodyListHttpData
2. The size of data that can be buffered in undecodedChunk awaiting decoding
3. The cumulative memory footprint of form field processing

This oversight allows attackers to craft specially designed chunked POST requests that force the decoder to allocate memory without restrictions.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Establishing a connection to a Netty-based HTTP server
2. Sending a chunked POST request with multipart/form-data content type
3. Including numerous small form fields in the request body
4. Continuing to send fields until the server's memory is exhausted

The chunked transfer encoding allows the attacker to maintain an open connection while continuously streaming malicious data, making the attack particularly effective against long-polling or streaming endpoints.

Technical details regarding the exploitation mechanism can be found in the GitHub Gist PoC provided by the security researcher.

Detection Methods for CVE-2024-29025

Indicators of Compromise

• Unusual memory consumption spikes on servers running Netty-based applications
• Long-duration HTTP POST connections with continuous chunked data transmission
• Increased garbage collection activity on Java-based Netty applications
• HTTP requests with abnormally high numbers of form fields in multipart POST requests

Detection Strategies

• Monitor JVM heap memory usage for Netty-based applications and alert on abnormal growth patterns
• Implement network-level detection for HTTP POST requests with excessive chunked segments
• Deploy application performance monitoring (APM) to track HttpPostRequestDecoder memory allocation patterns
• Configure SentinelOne to detect resource exhaustion patterns associated with this vulnerability

Monitoring Recommendations

• Establish baseline memory consumption metrics for Netty applications and alert on significant deviations
• Monitor for unusually long-lived HTTP connections with continuous POST data
• Track the count of form fields processed per request and flag anomalous values
• Review Netty application logs for out-of-memory errors or garbage collection warnings

How to Mitigate CVE-2024-29025

Immediate Actions Required

• Upgrade Netty to version 4.1.108.Final or later, which contains the fix for this vulnerability
• Review all applications and services using Netty to identify vulnerable deployments
• Implement request timeouts and connection limits at the load balancer or reverse proxy level
• Consider deploying Web Application Firewall (WAF) rules to limit POST request sizes and field counts

Patch Information

The vulnerability is fixed in Netty version 4.1.108.Final. The patch introduces limits on resource allocation during HTTP POST request decoding.

Refer to the GitHub Netty Commit for detailed code changes.

The official GitHub Security Advisory GHSA-5jpm-x58v-624v provides additional guidance from the Netty project.

Debian users should consult the Debian LTS Announcement for distribution-specific patching instructions.

Workarounds

• Implement application-level limits on the number of form fields accepted per request before passing to HttpPostRequestDecoder
• Configure upstream reverse proxies (nginx, HAProxy) to enforce maximum request body sizes and connection timeouts
• Deploy rate limiting on endpoints that accept multipart form data to reduce attack surface
• Monitor and kill connections that exceed reasonable thresholds for POST request duration or size

# Example nginx configuration to limit POST body size
# Add to server or location block
client_max_body_size 10m;
client_body_timeout 30s;
proxy_read_timeout 60s;