The EPSS score for CVE-2026-73051 (CVSS 6.3) is dangerously misleading. This isn't a routine medium-severity bug — it's a spec compliance failure in actix-http's HTTP/1.1 parser that creates a structural desync risk across your entire deployment chain.
The vulnerability: actix versions before 3.12.1 accept requests containing both Content-Length and Transfer-Encoding: chunked headers simultaneously. RFC 7230 section 3.3.3 is explicit — a server MUST reject these with 400. actix didn't. That's the analytical event, not the CVSS number.
Why this matters beyond the score: actix-web almost always runs behind reverse proxies (nginx, traefik, caddy, cloud load balancers). Those proxies canonicalize requests before forwarding — but they canonicalize differently. Some strip Content-Length and preserve Transfer-Encoding; others do the opposite. If your proxy's normalization diverges from what actix tolerates, the desync window opens. The attacker doesn't exploit actix directly — they exploit the gap between what your proxy sends and what actix accepts.
Three underappreciated risks demand your attention:
First, the lateral blast radius. Production actix sits behind authenticated proxies, so the "unauthenticated remote attacker" framing in the CVE is incomplete. An attacker who compromises any service in your backend pool can send malformed headers to actix — that's a far lower bar than external exploitation. Patching actix doesn't close this internal path.
Second, the forgotten architectural layer. Proxy configs, internal load balancer rules, WAF policies, and service-to-service contracts were written around actix's permissive behavior — not RFC compliance. The 3.12.1 patch will break some of these assumptions. Expect intermittent request failures, health check flapping, or backend desyncs as the remediation surface reveals hidden dependencies.
Third, the temporal gap. Organizations deprioritizing this CVE because of low EPSS will run mixed parsing surfaces — some backends patched to 3.12.1, others still permissive — during the remediation window. That inconsistency itself is the smuggling surface. You don't need a new parsing edge case; you need uneven deployment of the fix.
Immediate priorities: audit what your proxy does with ambiguous headers before and after the patch; test whether 3.12.1 rejects outright or attempts canonicalization (this behavior determines your next threat surface); verify that internal service-to-service trust boundaries still hold now that actix enforces strict parsing. The patch is necessary but insufficient — your architecture's hidden assumptions about header handling are the real exposure.