Summary
actix-http has HTTP/1.1 CL.TE Request Smuggling
A vulnerability in actix-http's HTTP/1.1 request parser allows an unauthenticated remote client to smuggle requests in deployments where a front-end HTTP intermediary and the Actix backend disagree about whether Content-Length or Transfer-Encoding: chunked defines the request body length.
Severity
Medium.
This is an HTTP request smuggling vulnerability that can be triggered over the network without application-level credentials. Exploitation requires a specific proxy topology: an upstream proxy, WAF, load balancer, or similar intermediary must use Content-Length framing while forwarding the conflicting Transfer-Encoding: chunked request to an Actix backend over a reused HTTP/1.1 connection.
Affected Versions
actix-http: versions up to and including 3.12.0
Description
HTTP/1.1 requests that contain both Content-Length and Transfer-Encoding: chunked are ambiguous and must be rejected by recipients to avoid request smuggling.
Affected versions of actix-http accepted a request with a syntactically valid Content-Length header and Transfer-Encoding: chunked on the same HTTP/1.1 message. The parser then selected chunked decoding instead of rejecting the conflicting framing signals.
In a CL.TE proxy topology, an intermediary may treat bytes after the declared Content-Length body as part of the first request, while the Actix backend stops at the terminating chunk marker and parses the remaining bytes on the backend connection as a second HTTP request. This creates a backend-side request desynchronization primitive.
The issue is limited to HTTP/1.1 request parsing.
Fixed Versions
This issue is fixed in actix-http 3.12.1.
The fix rejects HTTP/1.1 requests that contain both Content-Length and Transfer-Encoding: chunked instead of choosing one framing interpretation.
Mitigation
Users should upgrade to actix-http 3.12.1 or later.
Applications that depend on actix-http through actix-web, awc, or another Actix crate should ensure dependency resolution selects actix-http 3.12.1 or later. For example:
cargo update -p actix-http
If an immediate upgrade is not possible, configure all upstream HTTP intermediaries to reject HTTP/1.1 requests that contain both Content-Length and Transfer-Encoding, and avoid forwarding ambiguous request framing to Actix backends.
Credits
Actix thanks mufeedvh who disclosed this issue through coordinated disclosure.
Impact
HTTP request smuggling
- Attack Vector: Network, unauthenticated.
- Effect: Backend request desynchronization with low integrity impact to requests processed by the vulnerable Actix service.
- Scope: Actix services using affected
actix-httpversions behind an HTTP/1.1 intermediary that forwards ambiguousContent-LengthplusTransfer-Encoding: chunkedrequests and reuses backend connections.
No direct confidentiality, availability, or subsequent-system impact is scored for this advisory.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-XHJ4-VRGC-HR34? GHSA-XHJ4-VRGC-HR34 is a medium-severity security vulnerability in actix-http (rust), affecting versions < 3.12.1. It is fixed in 3.12.1.
- Which versions of actix-http are affected by GHSA-XHJ4-VRGC-HR34? actix-http (rust) versions < 3.12.1 is affected.
- Is there a fix for GHSA-XHJ4-VRGC-HR34? Yes. GHSA-XHJ4-VRGC-HR34 is fixed in 3.12.1. Upgrade to this version or later.
- Is GHSA-XHJ4-VRGC-HR34 exploitable, and should I be worried? Whether GHSA-XHJ4-VRGC-HR34 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-XHJ4-VRGC-HR34 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-XHJ4-VRGC-HR34? Upgrade
actix-httpto 3.12.1 or later.