CVE-2026-50560

What it actually does

CVE-2026-50560 is a denial-of-service weakness in Netty’s HTTP/2 handling before 4.1.135.Final and 4.2.15.Final. A client can manipulate the HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE setting so that Netty accepts and processes a request, forwards it or allows upstream application work to occur, and then fails while writing response headers. This creates an asymmetric resource-consumption condition similar in effect to HTTP/2 Rapid Reset, but with a different wire pattern: the expensive server-side work occurs before the connection/request fails, potentially consuming CPU, memory, event-loop capacity, backend/origin capacity, and logging/exception-handling resources.

Why it matters to the business

Internet-facing or high-traffic services built on vulnerable Netty versions can experience degraded performance or intermittent outages if targeted with crafted HTTP/2 traffic. The likely business impact is service instability, increased latency, failed requests, elevated infrastructure cost from autoscaling or retry storms, and operational load on engineering teams. The CVSS score indicates limited availability impact, EPSS is currently low, and the issue is not listed in CISA KEV, but Netty is widely embedded in Java services, API gateways, proxies, and application frameworks, so exposure can be broader than direct application dependency lists suggest.

How an attack unfolds

An unauthenticated remote attacker connects to a service that supports HTTP/2 and is implemented with or transitively depends on a vulnerable Netty release. The attacker sends HTTP/2 settings that advertise a restrictive SETTINGS_MAX_HEADER_LIST_SIZE value. Netty processes the request and may cause downstream application or origin work to be performed. When the service attempts to generate and write response headers, the response violates the negotiated header-list-size behavior and Netty raises an exception. Repeating this pattern across many streams or connections can create disproportionate server-side work and error handling compared with the attacker’s cost, leading to availability degradation. Unlike classic HTTP/2 Rapid Reset, defenders may not see a high rate of RST_STREAM frames as the primary signal; instead, they should look for abnormal HTTP/2 settings negotiation, response-header write failures, and spikes in Netty HTTP/2 exceptions.

How to fix it

Upgrade Netty to a patched release: 4.1.x users should upgrade to 4.1.135.Final or later, and 4.2.x users should upgrade to 4.2.15.Final or later. Because Netty is often included transitively through frameworks, application servers, RPC stacks, API gateways, service meshes, or SDKs, validate both direct and transitive dependency versions in all build artifacts and container images. If immediate upgrade is not possible, reduce exposure by disabling HTTP/2 where it is not required, terminating HTTP/2 at a patched reverse proxy or load balancer, enforcing sane limits on concurrent HTTP/2 streams and connections, applying rate limits per client/IP, tuning request and header-size limits consistently across proxy and application layers, and monitoring/reducing excessive exception logging that could amplify resource consumption.

How to confirm the fix worked

Confirm the deployed runtime uses Netty 4.1.135.Final, 4.2.15.Final, or later by inspecting dependency manifests, SBOMs, build lockfiles, shaded JAR contents, container image layers, and runtime classpath output. Validate that external endpoints either do not negotiate HTTP/2 or are fronted by patched HTTP/2 termination. In staging, send benign HTTP/2 traffic with low SETTINGS_MAX_HEADER_LIST_SIZE values and verify the service handles it without repeated response-header write exceptions, event-loop saturation, or backend amplification. Review dependency trees with tools such as Maven dependency:tree, Gradle dependencies/dependencyInsight, SCA scanners, and container image scanners to ensure no vulnerable Netty artifacts remain.

Typical attack path

1. Identify a public or reachable service that supports HTTP/2 and uses a vulnerable Netty version before 4.1.135.Final or 4.2.15.Final.
2. Open HTTP/2 connections to the target service.
3. Send SETTINGS frames containing a crafted or unusually low SETTINGS_MAX_HEADER_LIST_SIZE value.
4. Submit requests that trigger normal application/origin processing and response generation.
5. Cause Netty to fail while writing response headers due to the negotiated maximum header list size.
6. Repeat the sequence across many streams, connections, or source addresses to exhaust event-loop capacity, backend resources, or error-handling/logging capacity.

How to detect it

To determine whether exploitation has already occurred, review HTTP/2-capable edge logs, reverse proxy logs, load balancer telemetry, application logs, Netty logs, APM traces, and infrastructure metrics for periods of unusual latency, elevated 5xx responses, high CPU, event-loop saturation, connection churn, or exception storms. Focus on requests or connections where clients negotiated unusually small SETTINGS_MAX_HEADER_LIST_SIZE values followed by response failures. In application logs, look for Netty HTTP/2 exceptions during response-header encoding or writes, especially if clustered by source IP, ASN, user agent absence, or repeated connection creation. Network captures or HTTP/2-aware telemetry may show SETTINGS frames manipulating MAX_HEADER_LIST_SIZE without the high-volume RST_STREAM pattern typical of Rapid Reset. Also check for secondary effects such as backend/origin request volume increasing while successful responses decrease, which indicates the vulnerable server performed work before failing the response.

• SETTINGS_MAX_HEADER_LIST_SIZE
• MAX_HEADER_LIST_SIZE
• io.netty.handler.codec.http2
• Http2Exception
• Http2FrameCodec
• Http2ConnectionHandler
• Http2HeadersEncoder
• HeaderListSizeException
• header list size
• max header list size
• Header size exceeded
• HTTP/2 header
• RST_STREAM
• GOAWAY
• too_many_header_list_size
• failed to write headers
• exception while writing headers

What your security team should do

• Prioritize upgrading all applications, gateways, and services using Netty to 4.1.135.Final, 4.2.15.Final, or later, especially internet-facing HTTP/2 services.
• Inventory transitive Netty usage across Java applications, container images, vendor packages, and frameworks because affected code may be embedded rather than directly declared.
• Place compensating controls in front of unpatched services: patched reverse proxy termination, HTTP/2 disablement where feasible, connection and stream concurrency limits, and per-client rate limiting.
• Add monitoring for abnormal HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE usage, Netty HTTP/2 header-write exceptions, sudden increases in 5xx responses, connection churn, event-loop latency, and CPU spikes.
• Correlate application errors with load balancer, reverse proxy, and network telemetry to distinguish this issue from classic HTTP/2 Rapid Reset attacks, which may have a different RST_STREAM-heavy signature.
• Review logging configuration to prevent high-volume exception logging from becoming a secondary denial-of-service amplifier.
• Track exploit intelligence even though current EPSS is low and there is no KEV listing, because HTTP/2 denial-of-service techniques are often adapted quickly once implementation details are public.