CVE-2024-29025

What it actually does

This is a network-reachable denial-of-service flaw in Netty's HTTP multipart/form POST decoding logic. Applications that use vulnerable Netty versions and parse attacker-supplied form POST bodies with HttpPostRequestDecoder can be forced to retain an unbounded number of form fields in bodyListHttpData and to accumulate bytes in the undecodedChunk buffer. By sending a chunked HTTP POST containing many small fields, an unauthenticated remote attacker can drive excessive heap or direct memory consumption, increased garbage collection, request-processing stalls, and potentially process termination. The issue affects availability only; it does not directly provide code execution, privilege escalation, or data disclosure.

Why it matters to the business

Public-facing services built on affected Netty versions may become slow, unstable, or unavailable if targeted with crafted HTTP POST traffic. Because Netty is widely used as an embedded networking framework in Java services, the exposure may exist indirectly through applications, gateways, APIs, or products that bundle or shade Netty. The vulnerability has a moderate CVSS score, low EPSS, is not listed in CISA KEV, and has no known mature public exploit in the provided data, but it has been public since March 2024, so remediation should be handled as standard dependency hygiene for internet-facing and high-availability services.

How an attack unfolds

An attacker identifies an HTTP endpoint backed by a vulnerable Netty stack that accepts form-encoded or multipart POST requests and invokes HttpPostRequestDecoder. The attacker then opens one or more connections and sends chunked POST bodies made up of many small form fields. Because vulnerable decoder logic does not adequately limit the number of fields accumulated in bodyListHttpData or the amount of undecoded data buffered in undecodedChunk, memory usage grows as the request is processed. Repeating this across connections or requests can cause high memory pressure, garbage-collection churn, slow responses, connection resets, OutOfMemoryError conditions, or service crashes. No authentication or user interaction is required if the vulnerable endpoint is reachable anonymously.

How to fix it

Upgrade Netty to version 4.1.108.Final or later. For source-based tracking, ensure the fix containing commit 3a3f9d13b129555802de5652667ca0af662f554e is present. Review direct and transitive dependencies such as netty-codec-http, netty-all, and framework dependencies that embed Netty; also check for shaded or vendored Netty copies inside application artifacts. Where immediate upgrade is not possible, mitigate by enforcing request body size limits, form field count limits, multipart limits, reverse-proxy buffering limits, connection and request rate limits, and aggressive timeouts for slow or oversized POST bodies. Prefer rejecting unexpectedly large or highly fragmented chunked POST requests before they reach Netty-based application code.

How to confirm the fix worked

Confirm that all deployed Java artifacts resolve Netty 4.1.108.Final or later, or include the fixed commit if built from source. Use dependency tooling such as Maven dependency:tree, Gradle dependencies, SCA/SBOM scanners, and container image scanners to find vulnerable or shaded Netty components. At runtime, verify application startup logs, dependency manifests, JAR metadata, or build information for the active Netty version. Test exposed endpoints with safe, controlled negative tests that send chunked form POSTs with high field counts and confirm requests are rejected by configured limits without abnormal heap growth, direct memory growth, excessive garbage collection, or process instability.

Typical attack path

1. Discover an application or service using a vulnerable Netty version for HTTP request handling.
2. Identify an endpoint that accepts HTTP POST requests with form or multipart body parsing.
3. Send crafted chunked POST requests containing a very large number of small form fields or data fragments.
4. Force HttpPostRequestDecoder to accumulate excessive HttpData entries and undecoded bytes in memory.
5. Repeat or parallelize requests until the service experiences memory exhaustion, latency spikes, failed requests, or process termination.

How to detect it

There is no single definitive on-host artifact proving exploitation, so detection should correlate HTTP access logs, reverse-proxy logs, application logs, JVM telemetry, and infrastructure metrics. Look for bursts of HTTP POST requests using Transfer-Encoding: chunked and Content-Type values associated with form parsing, especially requests with extremely high parameter counts, many tiny chunks, long request durations, repeated connection resets, or unusually large request bodies relative to normal traffic. On application hosts, investigate time-correlated increases in heap usage, direct memory usage, garbage collection pauses, thread starvation, 5xx responses, container restarts, JVM crashes, or OutOfMemoryError events. Useful log sources include web server and load balancer access logs, API gateway logs, WAF logs, application logs containing Netty exceptions, JVM GC logs, container orchestrator restart events, APM traces, and host memory telemetry. For forensic review, correlate suspicious POST traffic with Java process memory growth and service instability; absence of these artifacts does not rule out attempted exploitation if upstream devices dropped or normalized the traffic.

• io.netty.handler.codec.http.multipart.HttpPostRequestDecoder
• bodyListHttpData
• undecodedChunk
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: Direct buffer memory
• io.netty.util.internal.OutOfDirectMemoryError
• Transfer-Encoding: chunked
• Content-Type: application/x-www-form-urlencoded
• Content-Type: multipart/form-data
• POST

What your security team should do

• Inventory applications, gateways, APIs, and vendor products that include Netty, especially internet-facing Java services that accept POST form uploads or multipart data.
• Prioritize upgrade to Netty 4.1.108.Final or later for externally reachable and high-availability services.
• Search dependency trees and SBOMs for netty-codec-http, netty-all, and shaded Netty copies that may not be obvious from top-level package names.
• Add or verify request body size, multipart/form field count, chunked transfer, timeout, and rate-limit controls at the reverse proxy, API gateway, and application layers.
• Monitor for memory pressure, OutOfMemoryError, direct memory exhaustion, abnormal garbage collection, and bursts of chunked POST requests with unusually high parameter counts.
• If upgrade is delayed, deploy compensating controls to reject excessive form fields and oversized or highly fragmented chunked POST bodies before Netty parsing occurs.
• Treat exploitation as availability-focused: prepare runbooks for traffic blocking, endpoint throttling, heap dump collection, and rapid service restart if active denial-of-service behavior is observed.