actix-http CVE-2026-73051

Exploitation requires a CL.TE proxy topology: a front-end intermediary (reverse proxy, WAF, CDN edge node, or load balancer) must be present, must forward HTTP/1.1 requests containing both Content-Length and Transfer-Encoding: chunked without rejection, and must reuse persistent backend connections to the Actix service. The front-end must interpret body length via Content-Length while the backend parser defers to chunked encoding - this disagreement is the exploitable condition. Direct connections from attacker to Actix backend (no intermediary) are not exploitable via this mechanism. Non-default configuration is not required on the Actix side; any actix-http deployment on an affected version behind an applicable intermediary is in scope. Exploitation is limited to HTTP/1.1 connections; HTTP/2 upstream traffic is not affected.

The CVSS 4.0 base score of 6.3 with vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N reflects the core tension of this vulnerability: the attack requires no authentication and no user interaction (PR:N, UI:N) but mandates a very specific intermediary topology (AT:P), which meaningfully constrains the real-world attacker population. Environments running Actix services directly exposed on the internet without a forwarding proxy, WAF, or load balancer in front are not exploitable by this vector. No EPSS score was provided in the input data, and the vulnerability is absent from the CISA KEV catalog, indicating no confirmed exploitation at time of analysis. The integrity impact is limited to low-severity request manipulation (VI:L) with no confidentiality or availability signal scored. Real-world risk is moderate for services operating behind HTTP/1.1 intermediaries that forward conflicting framing headers - a common enterprise deployment pattern - but the topology dependency prevents broad automated exploitation.

An attacker aware that a target site runs actix-web behind a load balancer or WAF crafts an HTTP/1.1 POST request with a Content-Length of 50 and a Transfer-Encoding: chunked body that terminates with a 0-byte chunk followed by a complete second HTTP request prefix. The front-end proxy reads 50 bytes per Content-Length and forwards the entire payload on a reused backend connection; the Actix parser consumes the chunked body and then reads the appended bytes as a fresh request, effectively injecting a request prefix that will be prepended to the next legitimate user request processed on that connection. No public proof-of-concept code has been identified, but the CL.TE technique is well-documented in open security research.