CVE-2026-56746

What it actually does

Netty's HTTP CORS handling contains an authorization bypass in CorsHandler when shortCircuit() is enabled. That setting is intended to reject disallowed cross-origin requests before they reach application code, but a logic error in origin evaluation allows requests with an Origin: null header to bypass the short-circuit rejection path. As a result, requests that should have been blocked by the framework-level CORS control can be forwarded to backend handlers. The flaw affects Netty 4.1.0.Final through 4.1.135.Final and 4.2.0.Final through 4.2.15.Final, and is fixed in 4.1.136.Final and 4.2.16.Final. The impact is integrity-focused: it may allow unauthorized state-changing requests to reach application logic if the application relies on Netty CORS short-circuiting as an access-control boundary.

Why it matters to the business

Applications that rely on Netty's CORS short-circuit behavior to stop unauthorized browser-originated requests may process requests they were expected to reject. This can lead to unauthorized changes, abuse of user sessions, unexpected transactions, or policy violations depending on what the exposed application endpoints allow. The CVSS score is medium at 6.5, EPSS is currently low at 0.00379, and it is not listed in CISA KEV, but remediation should still be prioritized for internet-facing services, administrative interfaces, APIs with state-changing operations, and widely reused platform components because Netty is commonly embedded in Java services and frameworks.

How an attack unfolds

An attacker identifies an application using a vulnerable Netty version with CorsHandler configured to short-circuit unauthorized origins. The attacker then causes a browser or client to issue a cross-origin request that includes Origin: null, which can occur from opaque origins such as sandboxed documents, local files, data URLs, or specially crafted browser contexts. Because of the origin-evaluation logic flaw, Netty does not reject the request at the CORS short-circuit layer and instead forwards it to the backend application. If the backend endpoint performs state-changing actions and depends on the CORS short-circuit check rather than independent authentication, authorization, CSRF protection, and origin validation, the unauthorized request may be accepted and processed. Exploit maturity is currently reported as none, so defenders should focus on exposure reduction, logging suspicious null-origin traffic, and validating application-layer controls.

How to fix it

Upgrade affected Netty components to a fixed release: 4.1.136.Final or later for the 4.1.x line, or 4.2.16.Final or later for the 4.2.x line. For Red Hat-packaged Netty, apply the vendor fix for codec-http provided in RHSA-2026:47172. Because Netty is often included transitively, review dependency trees and packaged application bundles, not only direct dependencies. If immediate upgrade is not possible, add compensating controls at the reverse proxy, gateway, WAF, or application layer to reject Origin: null for sensitive endpoints unless explicitly required. Do not rely on CORS as the sole access-control mechanism; enforce authentication, authorization, CSRF protections, and server-side origin validation on sensitive operations.

How to confirm the fix worked

Confirm that runtime and packaged dependencies no longer include vulnerable Netty codec-http versions: 4.1.0.Final through 4.1.135.Final or 4.2.0.Final through 4.2.15.Final. Validate dependency resolution using build tools such as Maven, Gradle, SBOM scanners, container image scanners, and application server inventory. Perform a controlled test against non-production or approved test endpoints by sending requests with Origin: null to routes expected to be blocked by CORS short-circuiting; after remediation, those requests should be rejected before reaching application business logic. Also verify that sensitive endpoints enforce independent authorization and CSRF protections even when requests pass CORS handling.

Typical attack path

1. Identify an application or API built on an affected Netty version, especially one using CorsHandler with shortCircuit() enabled.
2. Determine whether sensitive or state-changing endpoints depend on CORS short-circuiting as a protective control.
3. Craft or induce a cross-origin browser request that sends the header Origin: null.
4. Send the request to a protected endpoint that would normally be rejected because of its origin.
5. Rely on the Netty logic flaw to bypass the short-circuit CORS rejection and reach backend application handlers.
6. If backend authorization, CSRF, or request validation is insufficient, cause unauthorized state changes or abuse authenticated user context.

How to detect it

To assess possible prior exploitation, review HTTP access logs, reverse proxy logs, WAF logs, API gateway logs, application logs, and Netty request/debug logs for requests containing Origin: null that reached protected or state-changing endpoints. Focus on POST, PUT, PATCH, DELETE, and other non-idempotent operations, especially where responses indicate success, redirects after action completion, or application-level validation rather than CORS rejection. Compare events before and after patching or compensating controls: vulnerable behavior may show null-origin requests being forwarded to backend handlers instead of being rejected at the edge or CORS layer. Correlate suspicious requests with Referer, Sec-Fetch-* headers, user-agent anomalies, authenticated session use, CSRF validation failures or absences, and subsequent business actions such as configuration changes, profile updates, transactions, or permission changes. Because no public exploit maturity is reported in the input, treat Origin: null as a suspicious lead rather than proof of compromise, and confirm by matching it to sensitive endpoint access and successful state changes.

• Origin: null
• Origin:null
• origin: null
• origin:null
• Access-Control-Request-Method: POST
• Access-Control-Request-Method: PUT
• Access-Control-Request-Method: PATCH
• Access-Control-Request-Method: DELETE
• Sec-Fetch-Site: cross-site
• io.netty.handler.codec.http.cors.CorsHandler
• netty-codec-http-4.1.135.Final.jar
• netty-codec-http-4.2.15.Final.jar

What your security team should do

• Inventory all applications, containers, and third-party products that package Netty, especially netty-codec-http.
• Prioritize upgrades for internet-facing services, administrative consoles, APIs with write operations, and systems where browser-originated requests can affect user or business state.
• Upgrade to Netty 4.1.136.Final, 4.2.16.Final, or the applicable vendor-patched package such as Red Hat codec-http via RHSA-2026:47172.
• Add temporary gateway or WAF rules to block or challenge Origin: null requests to sensitive endpoints unless a documented business case requires them.
• Review application code to ensure CORS is not treated as the only authorization or CSRF defense.
• Enable or enhance HTTP access logging to capture Origin, Referer, Sec-Fetch-Site, request method, response status, authenticated user context where appropriate, and target path.
• Hunt historical logs for Origin: null requests that reached sensitive endpoints, especially POST, PUT, PATCH, and DELETE requests.
• Monitor vendor advisories and dependency updates because Netty is frequently pulled in through frameworks and downstream packages.