CVE-2026-44892: Netty HTTP/3 Header Memory Exhaustion DoS Vulnerability

Technical summary

The vulnerability exists in the `Http3ConnectionHandler` component of Netty's HTTP/3 codec. HTTP/3 includes a mechanism called `HTTP3_SETTINGS_MAX_FIELD_SECTION_SIZE` that allows peers to negotiate a maximum size for header blocks. In versions before 4.2.15.Final, when a peer does not explicitly set this parameter, Netty defaults to no limit rather than enforcing a reasonable upper bound. An attacker can send a crafted HTTP/3 request or response with an arbitrarily large header section, triggering unbounded memory allocation in the victim's process. When memory is exhausted, the JVM throws an `OutOfMemoryError`, terminating the application. The issue is classified under CWE-1188 (Insecure Default Initialization with Hard-Coded Network Resource Configuration Constant) and CWE-400 (Uncontrolled Resource Consumption).

Business impact

For organizations deploying Netty-based HTTP/3 services—including reverse proxies, API gateways, and custom protocol servers—this vulnerability creates an availability risk. A remote attacker requires no authentication or special privileges to trigger the denial of service. If a service relies on HTTP/3 for critical operations, an exploit could disrupt user-facing applications or backend integrations. The low attack complexity and network-based attack vector mean the threat can be realized by anyone with network access to the service. Organizations should prioritize patching to restore service resilience.

Affected systems

Applications built on Netty versions prior to 4.2.15.Final that enable the HTTP/3 codec and expose HTTP/3 endpoints are vulnerable. This includes Netty-based API gateways, load balancers, proxy servers, and custom protocol implementations that leverage the HTTP/3 handler. Notably, the vulnerability only manifests in deployments actively using HTTP/3; applications relying solely on HTTP/1.x or HTTP/2 are unaffected. Verify your dependency tree and confirm whether `Http3ConnectionHandler` is instantiated in your application.

Exploitability

This vulnerability has a low barrier to exploitation. The attack vector is network-based, requires no authentication or user interaction, and the attack complexity is low. Any network-capable host can craft and transmit an oversized HTTP/3 header section to a vulnerable endpoint. The simplicity of the attack—essentially sending many or large headers—makes it immediately actionable once an attacker identifies a vulnerable Netty HTTP/3 service. No special tools or expertise beyond basic network protocols are required. However, the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities catalog, suggesting active exploitation in the wild has not been widely reported as of the publication date.

Remediation

Upgrade Netty to version 4.2.15.Final or later. The patch enforces a secure default maximum header size limit for `Http3ConnectionHandler`, preventing unbounded memory consumption. Update your build configuration (Maven pom.xml, Gradle build.gradle, etc.) to pull the patched version and rebuild your application. If you cannot upgrade immediately, consider disabling HTTP/3 support or placing network-level controls (firewalls, WAF rules) that limit header size on inbound HTTP/3 traffic as a temporary mitigating control.

Patch guidance

Netty maintainers released version 4.2.15.Final containing the fix. To patch: 1. Review your current Netty version in your dependency manifest. 2. Update the Netty dependency to 4.2.15.Final or any later version in your build file. 3. Run a full test suite to confirm backward compatibility with your application code. 4. Deploy the updated binary to development, staging, and production environments. 5. Verify that HTTP/3 functionality continues to operate as expected after deployment. Consult the Netty release notes and advisory for any breaking changes or additional context specific to your version baseline.

Detection guidance

Monitor for signs of header-related memory exhaustion or sudden `OutOfMemoryError` exceptions in Netty application logs, particularly those running HTTP/3 handlers. Implement resource monitoring on affected services to alert on abnormal memory consumption spikes. Network-based detection is challenging without deep packet inspection (DPI), but anomalous patterns of large or numerous headers in HTTP/3 traffic could be flagged by advanced WAF or IDS/IPS rules configured to inspect QUIC/HTTP/3 streams. Log and alert on any exceptions originating from the `Http3ConnectionHandler` class. Baseline normal header sizes and request patterns, then look for deviations that correlate with performance degradation.

Why prioritize this

This vulnerability should be prioritized for patching because it affects availability—a core security pillar—with a HIGH CVSS score (7.5), a straightforward network attack vector, and no authentication requirement. Any organization exposing HTTP/3 services should treat this as urgent. The fix is simple (a version bump) and low-risk, making remediation efficient. Delayed patching extends the window during which a motivated attacker could disrupt service.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a HIGH severity due to the attack vector (network), low complexity, lack of privileges or user interaction required, and direct impact on availability (the denial-of-service outcome). The score does not account for confidentiality or integrity, as the vulnerability does not leak data or corrupt state—it solely exhausts resources. However, the real-world severity for any organization depends on whether HTTP/3 is actually enabled and exposed; internal-only services or those not using HTTP/3 carry zero practical risk.

Frequently asked questions