CVE-2024-1135

What it actually does

The flaw is an HTTP request parsing inconsistency involving malformed or conflicting Transfer-Encoding headers. A vulnerable backend accepts requests with multiple Transfer-Encoding values and treats them as chunked even when a later or conflicting value indicates otherwise. When the backend is behind a reverse proxy, load balancer, CDN, WAF, or cache that interprets the same request differently, an attacker can desynchronize the frontend and backend HTTP streams. This enables HTTP request smuggling, which can cause attacker-controlled data to be interpreted as a separate request, potentially bypassing routing rules, authentication checks, cache boundaries, or endpoint restrictions. The CVSS vector indicates a network-reachable, unauthenticated, low-complexity issue with high integrity impact.

Why it matters to the business

Applications exposed through layered HTTP infrastructure may allow unauthorized access to restricted functionality, cache poisoning, user-session interference, or manipulation of requests processed on behalf of other users. The vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has no reported mature public exploit in the supplied data, but it has been public for an extended period, so remediation should be prioritized for internet-facing services, API gateways, and systems where frontend and backend HTTP parsing differ.

How an attack unfolds

An attacker sends a specially crafted HTTP request to a service path handled by the vulnerable stack. The request contains conflicting or duplicated Transfer-Encoding headers designed so that the frontend component and backend component disagree about where the request ends. The frontend may forward what it believes is a single valid request, while the vulnerable backend interprets part of the message body as the beginning of another HTTP request. The attacker then uses this desynchronization to queue or inject a hidden request to a restricted endpoint, poison a shared cache entry, alter request context, or interfere with subsequent user traffic. Successful exploitation generally depends on the presence of an intermediary proxy, CDN, WAF, cache, or load balancer and on permissive handling of ambiguous HTTP/1.1 framing.

How to fix it

Upgrade affected components to fixed versions. For the supplied affected package metadata, upgrade @chainsafe/libp2p-noise to version 5.0.3 or later, and ensure source builds of chainsafe/js-libp2p-noise include the fixed commits fe306a6992d7199bf90654e86664f41304b0da67 and/or 790b039023c72005536831a3ab6ab16a04645883 as applicable to the maintained branch. For deployments affected through Gunicorn or an HTTP server stack, apply the vendor-provided patched release and rebuild/redeploy all dependent images. As compensating controls, configure edge proxies, load balancers, and WAFs to reject requests with multiple Transfer-Encoding headers, conflicting Transfer-Encoding values, both Content-Length and Transfer-Encoding where not explicitly supported, malformed chunked bodies, or obsolete line folding. Prefer consistent HTTP parsing across all layers, disable HTTP/1.1 request reuse where feasible for high-risk paths, and avoid caching responses to ambiguous or authenticated requests.

How to confirm the fix worked

Confirm that all deployed package manifests, lockfiles, container images, and runtime artifacts use fixed versions, including @chainsafe/libp2p-noise 5.0.3 or later where applicable, and that source builds contain the referenced fixed commits. Validate proxy and application behavior with safe negative tests that send duplicated or conflicting Transfer-Encoding headers through the full production-like request path; the expected result is consistent rejection, typically HTTP 400, by the first HTTP component that receives the request. Review WAF, proxy, CDN, and application server configuration to ensure ambiguous framing is rejected before reaching the backend. Confirm no vulnerable versions remain in SBOMs, dependency scans, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, container layers, or vendored source trees.

Typical attack path

1. Identify an internet-facing HTTP service using the vulnerable request parsing stack behind a proxy, CDN, WAF, cache, or load balancer.
2. Probe the service with ambiguous HTTP/1.1 requests containing duplicated or conflicting Transfer-Encoding headers.
3. Observe behavioral differences such as timing anomalies, unexpected 400 responses, backend errors, cache anomalies, or reflected content from queued requests.
4. Craft a desynchronization request that causes the backend to treat attacker-controlled bytes as a second HTTP request.
5. Target restricted routes, cacheable objects, or session-sensitive endpoints through the smuggled request.
6. Use the desynchronized state to bypass controls, poison cache content, manipulate user requests, or access functionality not normally reachable.

How to detect it

Investigate prior exploitation using logs from CDNs, WAFs, reverse proxies, load balancers, API gateways, application servers, backend access logs, cache logs, and network telemetry. Focus on HTTP/1.1 requests with duplicated Transfer-Encoding headers, conflicting Transfer-Encoding values such as chunked plus identity, malformed chunk sizes, requests containing both Transfer-Encoding and Content-Length, unusual 400/408/502/503 bursts, backend parser exceptions, delayed responses, and mismatched request counts between frontend and backend logs. Look for restricted endpoint access immediately following malformed framing requests from the same source IP or connection, unexplained cache entries for authenticated or sensitive paths, cache hits serving unexpected content, and anomalous requests where the logged method or path appears embedded inside a prior request body. Because no unique malware, file artifact, or actor-specific indicator is supplied, detection should be behavior-based and correlated across the full HTTP delivery chain.

• Transfer-Encoding: chunked
• Transfer-Encoding: identity
• Transfer-Encoding: gzip
• Transfer-Encoding: compress
• Transfer-Encoding: deflate
• Transfer-Encoding: chunked, identity
• Transfer-Encoding: identity, chunked
• Content-Length: 0
• Transfer-Encoding: chunked\r\nTransfer-Encoding: identity
• Transfer-Encoding: identity\r\nTransfer-Encoding: chunked
• Content-Length:
• 0\r\n\r\nGET /
• 0\r\n\r\nPOST /
• Invalid HTTP request line
• Invalid chunked transfer encoding
• Invalid Transfer-Encoding header
• duplicate Transfer-Encoding
• conflicting Transfer-Encoding
• malformed chunked body
• HTTP request smuggling
• HRS
• CL.TE
• TE.CL

What your security team should do

• Prioritize remediation for internet-facing services, API endpoints, authentication flows, admin routes, and applications behind reverse proxies, CDNs, WAFs, load balancers, or shared caches.
• Upgrade @chainsafe/libp2p-noise to 5.0.3 or later where present, and verify chainsafe/js-libp2p-noise source deployments include the fixed commit for the maintained branch.
• If Gunicorn or another affected HTTP parser is in use, patch the HTTP server component and redeploy all application containers or hosts that embed it.
• Add edge-layer rules to block duplicated Transfer-Encoding headers, conflicting Transfer-Encoding values, malformed chunked encoding, and requests containing both Transfer-Encoding and Content-Length unless explicitly normalized and safe.
• Search historical HTTP access logs, proxy logs, WAF events, CDN logs, and backend application logs for request-smuggling probes and ambiguous framing attempts.
• Review cache integrity and access logs for suspicious cache-key mismatches, unexpected responses served to unrelated users, or unauthorized hits to restricted endpoints.
• Run dependency and SBOM scans across repositories and container registries to locate transitive or vendored affected packages.
• Add regression tests to CI/CD that verify ambiguous HTTP framing is rejected consistently across the deployed proxy-to-backend chain.