CVE-2025-67735

What it actually does

This flaw is an improper input validation issue in Netty's HTTP request encoding path, specifically in io.netty.handler.codec.http.HttpRequestEncoder. If an application allows attacker-controlled data to influence an outbound HTTP request target or related request-line content, carriage return and line feed characters can be encoded into the HTTP stream. That can break the intended request structure and allow injection of additional HTTP headers or, depending on the downstream server/proxy behavior, HTTP request splitting or request smuggling-style behavior. The vulnerability is most relevant in Netty-based clients, gateways, reverse proxies, API clients, service meshes, or middleware that construct outbound HTTP requests from user-supplied URLs, paths, query strings, or redirect destinations.

Why it matters to the business

Successful exploitation can let an attacker manipulate how downstream services interpret requests, potentially bypassing routing or access-control assumptions, poisoning caches, altering headers used for authentication or authorization, or causing requests to be processed differently than intended. Because Netty is commonly embedded as a library inside Java services and frameworks, exposure may be indirect and difficult to identify without dependency analysis. The vulnerability is not currently listed in CISA KEV, is not marked as ransomware-used, has no known exploit maturity in the supplied data, and has a low EPSS score, so it should be treated as a moderate-priority patching item unless the affected component processes untrusted URLs or operates as an internet-facing proxy/gateway.

How an attack unfolds

An attacker first identifies a Netty-based application that constructs outbound HTTP requests using input they can influence, such as a URL fetcher, webhook integration, proxy endpoint, redirect handler, API gateway, or service-to-service request builder. The attacker supplies a request target containing CRLF characters, often URL-encoded as %0d%0a, followed by attacker-chosen header text or a crafted second request fragment. A vulnerable Netty HttpRequestEncoder fails to neutralize the CRLF sequence before writing the outbound HTTP request. The receiving HTTP server, intermediary proxy, cache, or load balancer may then parse the injected bytes as additional headers or as a split request. The attacker uses this parsing confusion to alter downstream behavior, such as injecting Host, X-Forwarded-*, Content-Length, Transfer-Encoding, Authorization-like, or cache-control headers, or to trigger request smuggling conditions where front-end and back-end components disagree about request boundaries.

How to fix it

Upgrade Netty to a version that includes the fix for commit e2d9d11c67f418c3d1e76b77dd7b93de36e47787, or consume a released package version from the Netty project that contains that commit. Because the supplied fixed-version data references the Git commit rather than a package version, organizations should verify their resolved Netty artifact includes this commit or a later security release. Rebuild and redeploy all applications, containers, shaded JARs, fat JARs, and vendor components that bundle vulnerable Netty code. As defense in depth, reject or canonicalize CR, LF, and other control characters in any user-controlled URL, path, query, redirect, webhook, proxy, or request-target input before it reaches Netty. Avoid constructing outbound HTTP requests by concatenating raw strings; use strict URI builders and allowlists for schemes, hosts, and paths. For proxy-like services, normalize and validate request targets before forwarding and ensure downstream proxies reject malformed request lines and headers.

How to confirm the fix worked

Confirm dependency resolution shows a Netty build that includes commit e2d9d11c67f418c3d1e76b77dd7b93de36e47787 or a later fixed release. Use software composition analysis, build manifests, SBOMs, Maven/Gradle dependency trees, and container image scans to locate all copies of io.netty artifacts, including transitive and shaded dependencies. Perform a targeted regression test by sending benign CRLF-bearing inputs such as encoded %0d%0a followed by a test header name through any feature that creates outbound HTTP requests; the application should reject the input, encode it safely, or ensure the downstream service does not receive an injected header or split request. Inspect packaged artifacts for the fixed Netty version or fixed class implementation, and verify runtime classpaths do not load an older Netty copy before the patched one.

Typical attack path

1. Locate an application or service using Netty to generate outbound HTTP requests.
2. Find an input path where untrusted data influences the outbound URL, path, query string, redirect destination, proxy target, or request target.
3. Submit payloads containing CRLF sequences, commonly encoded as %0d%0a or %0D%0A, followed by injected HTTP header syntax.
4. Observe whether the downstream service, proxy, or cache receives unexpected headers or altered request structure.
5. Refine the payload to inject security-relevant headers, manipulate routing, poison cache entries, or create request parsing ambiguity.
6. Use the altered downstream interpretation to bypass controls, access unintended resources, or disrupt service behavior.

How to detect it

To determine whether exploitation was attempted or successful, review application access logs, API gateway logs, reverse proxy logs, WAF logs, Netty service logs, outbound HTTP client logs, and downstream server logs for CRLF sequences in URL-like inputs or unexpected injected headers. Focus on parameters and endpoints that accept URLs, redirect destinations, webhook targets, proxy targets, callback URLs, fetch/import locations, or path/query values later used in outbound HTTP requests. Look for encoded CRLF strings such as %0d%0a, double-encoded variants such as %250d%250a, or decoded log entries where a single request appears to span multiple lines. On downstream systems, compare received headers against what the upstream application normally sends; suspicious signs include attacker-controlled Host, X-Forwarded-Host, X-Original-URL, X-Rewrite-URL, Content-Length, Transfer-Encoding, Connection, or cache-related headers. Investigate malformed HTTP parser errors, request smuggling alerts, duplicate or conflicting Content-Length and Transfer-Encoding headers, unexpected cache hits, anomalous 400/502 responses, and mismatched request counts between front-end and back-end proxies. If full packet capture or HTTP telemetry is available, inspect raw outbound requests from Netty-based services for literal CRLF bytes inside the request target followed by header-like text.

• %0d%0a
• %0D%0A
• %250d%250a
• %250D%250A
• \r\nHost:
• \r\nX-Forwarded-Host:
• \r\nX-Original-URL:
• \r\nX-Rewrite-URL:
• \r\nContent-Length:
• \r\nTransfer-Encoding:
• \r\nConnection:
• %0d%0aHost:
• %0d%0aX-Forwarded-Host:
• %0d%0aX-Original-URL:
• %0d%0aX-Rewrite-URL:
• %0d%0aContent-Length:
• %0d%0aTransfer-Encoding:
• %0d%0aConnection:
• %0D%0AHost:
• %0D%0AX-Forwarded-Host:
• %0D%0AContent-Length:
• %0D%0ATransfer-Encoding:
• Transfer-Encoding: chunked
• Content-Length: 0

What your security team should do

• Inventory all applications and third-party products that embed Netty, including transitive dependencies and shaded JARs.
• Prioritize patching internet-facing gateways, proxies, webhook processors, URL fetchers, redirect handlers, SSRF-sensitive services, and any component that builds outbound HTTP requests from untrusted input.
• Upgrade to a Netty build containing commit e2d9d11c67f418c3d1e76b77dd7b93de36e47787 or a later official fixed release, then rebuild and redeploy affected services.
• Add input validation that rejects CR, LF, NUL, and other control characters in URL, path, query, and request-target fields.
• Search historical logs for encoded and decoded CRLF injection attempts, especially requests containing %0d%0a followed by HTTP header names.
• Add SIEM detections for CRLF sequences in URL-like parameters, proxy target parameters, webhook URLs, redirect URLs, and outbound request construction errors.
• Review downstream proxies, caches, and load balancers for protections against request smuggling, duplicate Content-Length, and conflicting Content-Length/Transfer-Encoding behavior.
• Because there is no supplied KEV status, ransomware linkage, or known exploit maturity, handle as moderate urgency globally but elevate to high urgency where user-controlled outbound request generation is present.