CVE-2026-50560: Netty HTTP/2 DOS Vulnerability

CVE-2026-50560 Overview

CVE-2026-50560 affects Netty, a widely deployed network application framework used to build protocol servers and clients in Java. The flaw resides in Netty's handling of the HTTP/2 SETTINGS_MAX_HEADER_LIST_SIZE parameter. A remote client can send this setting to trigger an exception while Netty writes response headers, producing behavior similar to the HTTP/2 Rapid Reset class of attacks but with a distinct on-the-wire signature. The condition enables resource consumption against the server. Versions prior to 4.1.135.Final and 4.2.15.Final are vulnerable, and both releases contain the fix. The weakness is classified under [CWE-770: Allocation of Resources Without Limits or Throttling].

Critical Impact
Unauthenticated remote attackers can degrade availability of HTTP/2 services built on Netty by abusing client-controlled header size settings.

Affected Products

Netty versions prior to 4.1.135.Final (4.1.x branch)
Netty versions prior to 4.2.15.Final (4.2.x branch)
Applications and proxies that embed vulnerable Netty releases for HTTP/2 termination or forwarding

Discovery Timeline

2026-06-12 - CVE-2026-50560 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-50560

Vulnerability Analysis

The vulnerability is a denial-of-service condition rooted in how Netty handles HTTP/2 connection settings advertised by peers. RFC 9113 defines SETTINGS_MAX_HEADER_LIST_SIZE, which a client uses to inform the server of the maximum size of header lists it is willing to accept. According to the advisory, Netty reads an incoming request, proxies it to the origin, attempts to construct a response, and then raises an exception while writing response headers when the client-advertised limit is breached. The exception occurs after request work has already been performed, so the server expends compute and I/O resources on requests that ultimately fail at the header-write stage. Repeating this pattern at high volume yields impact comparable to the HTTP/2 Rapid Reset attack pattern, though with a different protocol signature that may evade detections tuned only for RST_STREAM floods.

Root Cause

The root cause is missing throttling and resource accounting around client-controlled HTTP/2 settings. Netty does not adequately constrain the work performed per stream when the negotiated header size makes successful response delivery impossible. This aligns with [CWE-770], where resources are allocated without limits relative to attacker-influenced parameters.

Attack Vector

The attack vector is network-reachable HTTP/2. An unauthenticated client opens an HTTP/2 connection, sends a SETTINGS frame configuring a small SETTINGS_MAX_HEADER_LIST_SIZE, then issues requests that will cause the server's responses to exceed that limit. Each request is processed and proxied upstream before failing during header serialization, amplifying resource consumption per request. See the Netty Security Advisory GHSA-563q-j3cm-6jxm and RFC 9113 Defined Settings for protocol-level context.

No verified proof-of-concept code is published for this CVE. The vulnerability mechanism is documented in prose in the upstream advisory.

Detection Methods for CVE-2026-50560

Indicators of Compromise

Elevated rate of HTTP/2 connections where peers advertise unusually small SETTINGS_MAX_HEADER_LIST_SIZE values shortly after connection establishment.
Spikes in exceptions thrown by Netty HTTP/2 codec classes during response header serialization, often correlated with upstream proxy traffic.
Sustained backend CPU and upstream request load with low successful HTTP/2 response counts on the edge.

Detection Strategies

Inspect HTTP/2 SETTINGS frames at the proxy or load balancer and alert on anomalous client-supplied values for SETTINGS_MAX_HEADER_LIST_SIZE.
Correlate Netty application logs containing header-write exceptions with per-source-IP request rates to identify abusive peers.
Track ratio of completed responses to accepted streams per connection; a low ratio combined with upstream work performed indicates abuse.

Monitoring Recommendations

Export Netty HTTP/2 codec metrics (stream resets, header encoder failures, connection lifetimes) to your SIEM or data lake for trend analysis.
Monitor upstream origin request counts versus client-facing successful responses to detect amplification patterns.
Centralize JVM exception telemetry from services embedding Netty so that header-encoding failures are queryable across the fleet.

How to Mitigate CVE-2026-50560

Immediate Actions Required

Upgrade Netty to 4.1.135.Final for 4.1.x deployments or 4.2.15.Final for 4.2.x deployments.
Inventory all applications, frameworks, and proxies that bundle Netty transitively, including reactive HTTP clients, gRPC stacks, and API gateways.
Rate-limit HTTP/2 connections at the network edge and constrain the number of concurrent streams and settings updates per client.

Patch Information

The Netty maintainers fixed the issue in Netty 4.1.135.Final and Netty 4.2.15.Final. The patched versions correct how SETTINGS_MAX_HEADER_LIST_SIZE is honored so that requests destined to fail at header write are short-circuited without performing the full proxy round trip. Refer to the GHSA-563q-j3cm-6jxm advisory for the authoritative fix description.

Workarounds

Place an HTTP/2-aware reverse proxy in front of Netty services and reject or normalize abnormal SETTINGS_MAX_HEADER_LIST_SIZE values.
Enforce stricter per-connection limits on concurrent streams, request rate, and connection lifetime to bound the cost of abusive peers.
Disable HTTP/2 termination on internet-exposed Netty endpoints until the patched version is deployed, where business requirements allow.

bash

# Example Maven dependency override pinning the patched Netty release
mvn versions:use-dep-version \
  -Dincludes=io.netty:netty-all \
  -DdepVersion=4.1.135.Final \
  -DforceVersion=true