CVE-2026-48043: Netty HTTP/2 Decompression Memory Leak DoS Vulnerability

Technical summary

The vulnerability exists in the `DelegatingDecompressorFrameListener` class within netty-codec-http2. This component manages per-stream decompression using embedded channels that decode gzip, deflate, or zstd compressed HTTP/2 frames. Decompressed data is passed as pooled `ByteBuf` objects to a tail-handler responsible for release. When the flow controller encounters an error on certain malformed frames, it can throw an exception before the handler releases the buffer, causing a leak. Accumulation of unreleased buffers eventually triggers out-of-memory conditions.

Business impact

Applications using Netty for HTTP/2 communication face denial-of-service risk. An unauthenticated remote attacker can trigger memory exhaustion leading to application crashes or full JVM termination. This impacts service availability and can force unexpected restarts or require manual intervention. Organizations running microservices or APIs on Netty should prioritize patching to maintain uptime.

Affected systems

Netty netty versions prior to 4.1.135.Final (4.1.x branch) and prior to 4.2.15.Final (4.2.x branch) are vulnerable. Any application embedding netty-codec-http2 and processing HTTP/2 connections is at risk. Verify your exact Netty version in your build files (Maven pom.xml, Gradle build.gradle, etc.) and confirm which branch you are on.

Exploitability

Exploitation requires no special privileges or user interaction. An attacker needs only network access to send HTTP/2 frames to the vulnerable application. The attack is straightforward: send a series of malformed frames that trigger decompression errors, causing buffers to leak until memory exhaustion. No CVSS exploit complexity penalty applies because the condition can be reliably triggered remotely.

Remediation

Upgrade netty-codec-http2 to version 4.1.135.Final or later if on the 4.1.x line, or to 4.2.15.Final or later if on the 4.2.x line. These versions fix the resource leak by ensuring buffers are released even when flow-control errors occur. After patching, validate that your application starts cleanly and test with your normal HTTP/2 traffic loads.

Patch guidance

1. Identify your current Netty version in your dependency management system. 2. Update netty-codec-http2 (and other Netty modules if applicable) to the patched version. 3. Run your test suite, especially integration tests exercising HTTP/2 decompression with various content encodings. 4. Monitor application logs for any decompression-related warnings after upgrading. 5. Roll out to production in your standard change window; no special compatibility breaks are expected.

Detection guidance

Look for signs of memory pressure in running Netty applications: increasing heap usage over time without corresponding traffic increases, frequent full garbage collection pauses, or OutOfMemoryError exceptions in logs. Enable detailed JVM heap dumps before service crashes to analyze buffer allocation patterns. If feasible, use network monitoring to detect patterns of malformed HTTP/2 frames being sent to your endpoints. Test by sending HTTP/2 frames with invalid compression headers and observe whether buffer counts climb unexpectedly.

Why prioritize this

While the CVSS score of 5.3 reflects the medium severity (denial-of-service only, no data breach), the practical impact is significant because it requires no authentication and can crash production services. Any publicly exposed Netty HTTP/2 endpoint is a direct target. Prioritize this patch for internet-facing applications; internal-only services have lower urgency but should still be addressed within your normal patching cycle.

Risk score, explained

The CVSS:3.1 score of 5.3 (MEDIUM) reflects: Attack Vector=Network (exploitable remotely), Attack Complexity=Low (no special conditions needed), Privileges Required=None, User Interaction=None, Scope=Unchanged, and Availability impact=Low per CVSS rating conventions. However, 'Low' availability impact in CVSS terms means the service can be degraded; in this case, total crash is achievable through sustained attack, making real-world impact potentially high for organizations dependent on continuous availability.

Frequently asked questions