CVE-2026-50560: Netty HTTP/2 Header Size DoS Vulnerability

Technical summary

The vulnerability resides in Netty's HTTP/2 implementation, specifically in the handling of the SETTINGS_MAX_HEADER_LIST_SIZE setting. When a client sends this setting, Netty processes the inbound request and forwards it to an origin server. However, when constructing the outbound response headers, Netty fails to properly validate or handle header sizes against the negotiated limit, leading to an exception during header serialization. This exception can be triggered repeatedly by an attacker sending crafted HTTP/2 frames, creating a denial-of-service condition. The root cause maps to CWE-770 (Allocation of Resources Without Limits or Throttling), as Netty does not adequately throttle or limit resource consumption during header processing.

Business impact

Applications and proxies built on Netty—including API gateways, load balancers, reverse proxies, and microservice frameworks—become susceptible to availability attacks. An attacker with network access can send a low volume of HTTP/2 requests with specifically crafted SETTINGS_MAX_HEADER_LIST_SIZE values to crash or exhaust resources in the Netty process, rendering the service unavailable to legitimate traffic. This is particularly concerning for critical infrastructure, financial systems, and any internet-facing service relying on Netty. The attack requires no authentication or special privileges, making it accessible to any network-adjacent threat actor.

Affected systems

Netty versions 4.1.x prior to 4.1.135.Final and 4.2.x prior to 4.2.15.Final are affected. Any application or service using these versions and exposing HTTP/2 endpoints is at risk. This includes but is not limited to Spring Cloud Gateway, gRPC-Java (which uses Netty), Project Reactor Netty, and custom protocol implementations built directly on Netty. Organizations should inventory all services using Netty and cross-reference against the fixed versions.

Exploitability

This vulnerability is readily exploitable. No authentication, user interaction, or special network privileges are required. An attacker with basic network access to an affected Netty HTTP/2 service can trigger the flaw by sending standard HTTP/2 frames with a low SETTINGS_MAX_HEADER_LIST_SIZE value, causing immediate denial of service. The attack surface is broad for any internet-facing HTTP/2 service. However, the vulnerability is not currently listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, suggesting active exploitation in the wild has not yet been officially confirmed at publication time.

Remediation

Upgrade Netty to version 4.1.135.Final or later for the 4.1.x branch, or to version 4.2.15.Final or later for the 4.2.x branch. These versions include fixes that properly validate and enforce the SETTINGS_MAX_HEADER_LIST_SIZE limit, preventing the header serialization exception. For applications using Netty indirectly through frameworks like Spring Cloud Gateway or Project Reactor Netty, ensure those frameworks have released and deployed updates incorporating the patched Netty version.

Patch guidance

1. Identify all services running Netty by checking dependency manifests (pom.xml for Maven, build.gradle for Gradle, etc.) or runtime introspection. 2. For 4.1.x users, upgrade to 4.1.135.Final; for 4.2.x users, upgrade to 4.2.15.Final. Check the Netty release notes to confirm no breaking changes affect your implementation. 3. For transitive Netty dependencies, update parent frameworks (e.g., Spring Boot, Spring Cloud Gateway, gRPC-Java) to versions that include the patched Netty. 4. Test thoroughly in a staging environment, especially HTTP/2 workloads, before production rollout. 5. Schedule upgrades promptly given the ease of exploitation.

Detection guidance

Monitor for HTTP/2 SETTINGS frames with unusually small or crafted SETTINGS_MAX_HEADER_LIST_SIZE values originating from external or suspicious sources. Watch application logs for repeated 'header serialization' or 'header size limit' exceptions correlated with HTTP/2 traffic spikes. Network-level detection could flag repeated SETTINGS_MAX_HEADER_LIST_SIZE changes from the same source within a short time window. Consider deploying WAF or reverse-proxy rules to rate-limit or block HTTP/2 SETTINGS frames that appear anomalous. Correlation of these signals with service availability degradation may indicate active exploitation.

Why prioritize this

Although the CVSS score of 5.3 (MEDIUM) reflects limited confidentiality and integrity impact, the availability attack is trivial to execute and affects core infrastructure layers. HTTP/2 is increasingly common; many organizations do not yet inventory Netty adoption. The lack of KEV designation should not delay patching—it may simply reflect a publication lag. Organizations running internet-facing Netty HTTP/2 services should treat this as a high-priority patch due to ease of exploitation and broad potential blast radius.

Risk score, explained

The CVSS 3.1 score of 5.3 reflects a network-accessible vulnerability (AV:N) with low complexity (AC:L), requiring no privileges (PR:N) or user interaction (UI:N), and causing low availability impact (A:L) in an unchanged scope (S:U). There is no confidentiality (C:N) or integrity (I:N) impact. However, this score underweights the practical threat: the attack is trivial, repeatable, and can be launched at scale. In operational risk terms, the ease of exploitation and the criticality of availability for many services warrant treating this above the MEDIUM baseline.

Frequently asked questions