CVE-2026-93568: Netty Auth Bypass Vulnerability

CVE-2026-93568 Overview

A flaw in the Netty asynchronous event-driven network application framework allows remote attackers to bypass application security policies. The vulnerability affects Netty's HTTP-object conversion path, which incorrectly processes HTTP/2 and HTTP/3 Extended CONNECT requests as regular HTTP/1.1 CONNECT requests. This misinterpretation causes a loss of critical protocol and path information. Applications relying on Netty for HTTP/2 or HTTP/3 communication may lose enforcement of routing or authorization logic. The weakness is classified as improper input validation [CWE-20].

Critical Impact
Remote attackers can send crafted Extended CONNECT requests over HTTP/2 or HTTP/3 to bypass security controls such as routing and authorization checks, resulting in integrity loss for downstream services.

Affected Products

Netty framework (versions incorporating the vulnerable HTTP-object conversion path)
Red Hat products bundling affected Netty versions (see RHSA-2026:69440, RHSA-2026:69470, RHSA-2026:70257)
Java applications and middleware built on Netty for HTTP/2 or HTTP/3 communication

Discovery Timeline

2026-09-18 - CVE-2026-93568 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93568

Vulnerability Analysis

The vulnerability resides in Netty's HTTP-object conversion path. HTTP/2 (RFC 8441) and HTTP/3 (RFC 9220) define the Extended CONNECT method to tunnel non-TCP protocols such as WebSockets over multiplexed streams. Extended CONNECT relies on pseudo-headers, including :protocol, :scheme, and :path, to convey routing information.

Netty's conversion logic downgrades these requests into an HTTP/1.1 CONNECT representation. Standard HTTP/1.1 CONNECT does not carry :protocol or :path, so this normalization discards those pseudo-headers. Downstream handlers then evaluate a request that no longer matches the client's original intent.

Applications enforcing authorization or routing decisions on path or protocol values receive a truncated view of the request. Attackers can exploit this discrepancy to reach protected endpoints or invoke tunneling behavior that policy would otherwise block.

Root Cause

The root cause is improper input validation [CWE-20] during protocol translation. Netty does not preserve or reject the Extended CONNECT-specific pseudo-headers when converting HTTP/2 or HTTP/3 frames into internal HTTP/1.1 objects. The conversion silently loses the :protocol and :path context that security middleware depends on.

Attack Vector

Exploitation requires network access to a service that terminates HTTP/2 or HTTP/3 traffic through Netty. No authentication or user interaction is required. An attacker sends a specially crafted Extended CONNECT request over an established HTTP/2 or HTTP/3 session. The framework's conversion path strips protocol and path information before request handlers evaluate authorization rules, enabling policy bypass. Confidentiality and availability are not directly affected; the primary impact is integrity loss through unauthorized routing.

See the Red Hat CVE Details for CVE-2026-93568 and the Red Hat Bug Report #2536961 for additional technical context.

Detection Methods for CVE-2026-93568

Indicators of Compromise

HTTP/2 or HTTP/3 request logs containing the CONNECT method paired with a :protocol pseudo-header value such as websocket.
Application access logs showing successful requests to protected endpoints without corresponding authorization decisions logged by upstream middleware.
Anomalous CONNECT method requests reaching backend services that historically process only GET, POST, or PUT traffic.

Detection Strategies

Instrument Netty pipelines to log incoming HTTP/2 and HTTP/3 pseudo-headers before conversion, and compare against post-conversion request objects.
Deploy web application firewall rules that flag Extended CONNECT requests routed to services not intended to accept tunneled protocols.
Correlate authorization middleware logs with backend handler logs to identify requests that bypass policy checks.

Monitoring Recommendations

Monitor traffic patterns for unexpected CONNECT method activity across HTTP/2 and HTTP/3 endpoints exposed to untrusted networks.
Track dependency inventories to identify services running vulnerable Netty versions and prioritize them for patching.
Alert on discrepancies between reverse proxy request logs and Netty-based application request logs for the same session.

How to Mitigate CVE-2026-93568

Immediate Actions Required

Inventory all Java services that embed Netty and identify those handling HTTP/2 or HTTP/3 traffic from untrusted networks.
Apply vendor patches from Red Hat advisories RHSA-2026:69440, RHSA-2026:69470, and RHSA-2026:70257 as soon as they are validated in staging.
Restrict exposure of HTTP/2 and HTTP/3 endpoints to trusted clients until patches are deployed.

Patch Information

Red Hat has published security advisories addressing the flaw for supported product streams. Consult RHSA-2026:69440, RHSA-2026:69470, and RHSA-2026:70257 for fixed package versions. Upstream Netty maintainers ship corrected HTTP-object conversion logic that preserves Extended CONNECT semantics or rejects malformed requests. Consumers building on Netty should upgrade to the patched release referenced in the Red Hat CVE record.

Workarounds

Disable HTTP/2 and HTTP/3 support on Netty-based listeners where those protocols are not required.
Front Netty services with a reverse proxy that terminates HTTP/2 and HTTP/3, validates pseudo-headers, and forwards only sanitized requests.
Add an inbound handler that rejects requests where the original HTTP/2 or HTTP/3 method is CONNECT with a :protocol pseudo-header, before the request reaches business logic.

bash

# Configuration example: block Extended CONNECT at a fronting proxy (nginx)
# Reject CONNECT method requests forwarded to upstream Netty services
map $request_method $block_connect {
    default 0;
    CONNECT 1;
}

server {
    listen 443 ssl http2;
    if ($block_connect) { return 405; }
    location / { proxy_pass http://netty_backend; }
}