CVE-2026-33870

What it actually does

CVE-2026-33870 is an HTTP/1.1 request parsing flaw in Netty before 4.1.132.Final and 4.2.10.Final. Netty incorrectly parses quoted strings inside chunked transfer encoding extension values, which can cause Netty and an upstream or downstream HTTP intermediary to disagree about where one request ends and the next begins. In deployments where Netty-based services sit behind or in front of proxies, gateways, load balancers, caches, or other HTTP parsers, this parser differential can enable HTTP request smuggling. The primary technical impact is integrity compromise: an attacker can desynchronize HTTP request streams, potentially injecting a hidden request, bypassing routing or security controls, poisoning queues or caches, or causing another user's request to be interpreted in an attacker-influenced context.

Why it matters to the business

Successful exploitation can allow attackers to manipulate how web requests are processed by Java services using vulnerable Netty versions. In practical terms, this may lead to unauthorized actions, bypass of access controls implemented at gateways or proxies, cache poisoning, request misrouting, or exposure of sensitive application behavior. The risk is highest for internet-facing services, API gateways, reverse proxies, service meshes, and custom Java applications that accept HTTP/1.1 chunked requests and use Netty directly or through frameworks built on Netty. Although this issue is not listed in CISA KEV and has low EPSS at this time, Netty is widely used in modern Java network stacks, so exposure may exist indirectly through application frameworks and dependencies.

How an attack unfolds

An attacker sends a specially crafted HTTP/1.1 request using Transfer-Encoding: chunked and includes malformed or ambiguous quoted strings in chunk extension values. Because vulnerable Netty versions parse those quoted chunk extensions differently than another HTTP component in the path, the frontend and backend can become desynchronized about the request boundary. The attacker then appends a second HTTP request in the same connection. One component may treat that appended data as part of the first request body, while the other treats it as a separate request. If the smuggled request reaches the application with trusted connection context or bypasses normal frontend enforcement, the attacker may be able to invoke unintended endpoints, alter request routing, poison shared responses, or interfere with subsequent users' requests on the same HTTP connection. Exploitation depends on the surrounding HTTP chain and is most plausible where Netty is combined with proxies, load balancers, gateways, caches, or other intermediaries that parse chunked encoding differently.

How to fix it

Upgrade Netty to a fixed release: 4.1.132.Final or later for the 4.1.x line, or 4.2.10.Final or later for the 4.2.x line. Because Netty is often pulled in transitively, review dependency trees for direct and indirect Netty artifacts and update parent frameworks or dependency management rules where necessary. If immediate upgrade is not possible, reduce exposure by disabling or restricting HTTP/1.1 chunked requests at the edge where feasible, normalizing requests at a trusted reverse proxy, rejecting chunk extensions with quoted values, avoiding mixed HTTP parser chains, and disabling backend connection reuse for high-risk paths as a temporary mitigation. Ensure all Netty-related modules are consistently upgraded rather than leaving mixed vulnerable artifacts in the application classpath.

How to confirm the fix worked

Confirm the deployed application no longer includes Netty versions earlier than 4.1.132.Final or 4.2.10.Final. Use build tooling such as Maven dependency:tree, Gradle dependencies, software composition analysis, container image scanning, and runtime classpath inspection to verify the effective Netty version. Test externally exposed HTTP endpoints to confirm ambiguous HTTP/1.1 chunked requests with quoted chunk extensions are rejected, normalized, or parsed consistently. Validate that reverse proxies, load balancers, API gateways, and backend Netty services agree on request boundaries and do not allow smuggled requests over reused connections. After deployment, monitor for a drop in malformed chunked-transfer parsing errors and ensure no service remains pinned to vulnerable transitive dependencies.

Typical attack path

1. Identify a service or application stack using a vulnerable Netty version before 4.1.132.Final or 4.2.10.Final.
2. Confirm the target accepts HTTP/1.1 requests with Transfer-Encoding: chunked.
3. Probe for parser differentials by sending chunked requests containing quoted chunk extension values and observing timing, response splitting, connection reuse, or anomalous backend behavior.
4. Craft a desynchronization payload where the frontend and Netty disagree about chunk boundaries or quoted extension parsing.
5. Append a hidden HTTP request after the ambiguous chunked body.
6. Use the smuggled request to reach internal routes, bypass frontend controls, poison a cache, alter request sequencing, or affect another request sharing the same connection.
7. Repeat and tune the payload based on response behavior, proxy behavior, and whether connections are reused.

How to detect it

Investigate whether the service received malformed HTTP/1.1 chunked requests, especially requests containing Transfer-Encoding: chunked with chunk extension values that include quotes, escaped quotes, unusual semicolons, or malformed chunk-size lines. Review reverse proxy, load balancer, WAF, CDN, API gateway, and application access logs for repeated 400, 408, 413, 414, 431, 502, or 504 responses associated with unusual chunked requests or connection reuse anomalies. Look for sequences where a benign-looking request is followed immediately by an unexpected request on the same client connection, especially to administrative, internal, metadata, cacheable, or authentication-sensitive endpoints. Inspect Netty application logs for decoder exceptions, bad request parsing errors, premature connection closures, unexpected HTTP method tokens in request bodies, or invalid chunk extension parsing. Where full packet capture or HTTP telemetry is available, search for raw HTTP/1.1 payloads containing chunk extensions with quoted strings followed by additional HTTP request lines in the same TCP stream. No public exploitation campaigns or KEV listing are currently indicated in the provided data, so detection should focus on behavioral evidence of HTTP request smuggling and malformed chunked-transfer probing.

• Transfer-Encoding: chunked
• ;"
• =\"
• io.netty.handler.codec.http
• io.netty.handler.codec.http.HttpObjectDecoder
• io.netty.handler.codec.http.HttpRequestDecoder
• DecoderException
• invalid chunk
• malformed chunk
• bad chunk
• chunk extension
• GET / HTTP/1.1
• POST / HTTP/1.1
• HTTP/1.1 400
• HTTP/1.1 502

What your security team should do

• Inventory internet-facing and internal Java services, API gateways, RPC bridges, and frameworks that include Netty, including transitive dependencies.
• Prioritize upgrades for externally reachable services and systems behind reverse proxies, load balancers, CDNs, service meshes, or HTTP caches.
• Upgrade Netty to 4.1.132.Final or later, or 4.2.10.Final or later, and rebuild/redeploy affected applications and container images.
• Use dependency scanning and SBOM tooling to detect vulnerable Netty artifacts across source repositories, CI/CD pipelines, containers, and deployed packages.
• Add edge-layer controls to reject malformed chunked transfer encoding and suspicious chunk extension syntax while upgrades are in progress.
• Review proxy and gateway configurations for backend HTTP/1.1 connection reuse, request normalization, and inconsistent handling of Transfer-Encoding and Content-Length.
• Run request-smuggling validation tests in staging and, where authorized, against production edge endpoints.
• Monitor access logs, WAF logs, proxy logs, and application logs for malformed chunked requests, repeated 400/502 responses, desynchronization symptoms, and unexpected requests to sensitive paths.