CVE-2026-50560: 
Java vulnerability analysis and mitigation

CVE-2026-50560 is a denial-of-service vulnerability in Netty's HTTP/2 implementation, specifically in the io.netty:netty-codec-http2 package, where improper handling of the SETTINGS_MAX_HEADER_LIST_SIZE setting produces an attack functionally similar to the HTTP/2 Rapid Reset Attack but with a different on-the-wire signature. It affects Netty versions prior to 4.1.135.Final (all 4.1.x releases) and versions 4.2.0.Final through 4.2.14.Final. The vulnerability was discovered by Jonathan Looney of Netflix Engineering, published as a GitHub Security Advisory (GHSA-563q-j3cm-6jxm) on June 8, 2026, and assigned a CVE on June 12, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (Github Advisory, Netty Advisory).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). The HTTP/2 specification defines SETTINGS_MAX_HEADER_LIST_SIZE as an advisory setting informing a peer of the maximum field section size it will accept; servers are not required to honor it. However, when a client sends this setting to a vulnerable Netty server, Netty incorrectly enforces it during response header writing: it reads the request, proxies it to the origin, attempts to produce a response, and then throws an exception when writing the response headers — effectively aborting the response. This behavior can be triggered repeatedly by an unauthenticated remote attacker with no special privileges or user interaction, requiring only network access to an HTTP/2-enabled Netty endpoint. The fix treats SETTINGS_MAX_HEADER_LIST_SIZE received from clients as advisory and ignores it, consistent with other HTTP/2 implementations (Netty Advisory, Github Advisory).

Successful exploitation results in a denial-of-service condition affecting the availability of the Netty-based application. An unauthenticated attacker can repeatedly send crafted HTTP/2 requests with a manipulated SETTINGS_MAX_HEADER_LIST_SIZE value, causing the server to exhaust resources processing requests it cannot complete, degrading or crashing the service. There is no impact on confidentiality or integrity — the vulnerability is purely an availability issue with no lateral movement or data exposure risk (Github Advisory, Netty Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of active in-the-wild exploitation at this time. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.018% (Feedly data) to 0.302% (GitHub Advisory), placing it in a low-to-moderate exploitation probability range. The attack requires no authentication, no user interaction, and no special configuration, making it straightforward to attempt if a PoC were developed (Github Advisory, Netty Advisory).

1. Reconnaissance: Identify internet-facing services built on Netty with HTTP/2 enabled (e.g., using Shodan or Censys to find services advertising HTTP/2 via ALPN). Confirm the target is running a vulnerable Netty version (prior to 4.1.135.Final or 4.2.0.Final–4.2.14.Final).
2. Establish HTTP/2 connection: Open an HTTP/2 connection to the target server using a tool or custom client capable of sending raw HTTP/2 frames (e.g., h2load, nghttp, or a custom script using an HTTP/2 library).
3. Send malicious SETTINGS frame: Transmit an HTTP/2 SETTINGS frame to the server containing a very small or restrictive SETTINGS_MAX_HEADER_LIST_SIZE value, below the size of typical response headers the server would generate.
4. Send HTTP/2 requests: Issue HTTP/2 requests over the same connection. Netty will read each request, proxy it to the origin, attempt to write response headers, and then throw an exception because the response headers exceed the client-advertised SETTINGS_MAX_HEADER_LIST_SIZE.
5. Repeat at scale: Repeat steps 3–4 in a loop or across multiple connections to amplify resource exhaustion on the server, causing degraded performance or a crash analogous to the HTTP/2 Rapid Reset Attack (Netty Advisory, Github Advisory).

• Network: High volumes of HTTP/2 connections from one or more source IPs sending SETTINGS frames with unusually small SETTINGS_MAX_HEADER_LIST_SIZE values; elevated rate of HTTP/2 stream resets or connection errors from the server side.
• Logs: Repeated Java exceptions in Netty application logs related to header size violations or response header writing failures (e.g., Http2Exception or similar stack traces in netty-codec-http2); unusual spikes in error-level log entries correlated with specific client IPs.
• Process/Resource: Abnormal CPU or memory consumption by the Netty server process without a corresponding increase in legitimate traffic; thread pool exhaustion or connection queue buildup observable via JVM metrics or monitoring tools.

Upgrade to Netty 4.1.135.Final (for the 4.1.x branch) or 4.2.15.Final (for the 4.2.x branch), which fix the issue by treating the client-sent SETTINGS_MAX_HEADER_LIST_SIZE as advisory and ignoring it during response header writing. No official configuration-based workaround has been published; upgrading is the recommended and only confirmed remediation. As a defense-in-depth measure, consider implementing rate limiting on HTTP/2 connections and header size validation at the network edge or load balancer layer. IBM Enterprise Build of Quarkus users should also apply the relevant IBM security bulletin update (Netty 4.1.135 Release, Netty 4.2.15 Release, IBM Advisory).

The vulnerability was reported by Jonathan Looney of Netflix Engineering and coordinated through Ashley Tolbert of Netflix Security, indicating proactive responsible disclosure from a major industry stakeholder. Red Hat has acknowledged the vulnerability and issued errata (RHSA-2026:26017 and RHSA-2026:26018) for affected products. IBM also published a security bulletin for IBM Enterprise Build of Quarkus affected by this and related Netty vulnerabilities (Red Hat CVE, IBM Advisory).