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.
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.
actix-http: versions up to and including 3.12.0HTTP/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.
HTTP request smuggling
actix-http versions behind an HTTP/1.1 intermediary that forwards ambiguous Content-Length plus Transfer-Encoding: chunked requests and reuses backend connections.No direct confidentiality, availability, or subsequent-system impact is scored for this advisory.
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.
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.
Actix thanks mufeedvh who disclosed this issue through coordinated disclosure.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도(기본값(정보 없음)) | 55.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 55.00 |
VPI 공식 vpi-v1 기준