Tinyproxy CVE-2026-54388

Exploitation requires only network reachability to a Tinyproxy instance at or below version 1.11.3 that is forwarding HTTP traffic to a backend whose Content-Length parser disagrees with Tinyproxy's first-header preference (a near-universal condition given common backends like nginx, Apache, and Node-based services). No authentication, configuration toggle, or user interaction is required, matching the CVSS PR:N/UI:N/AT:N metrics. The principal limiting factors are: the deployment must actually proxy HTTP (not just HTTPS CONNECT tunnels, where the proxy does not parse request bodies), the backend must be one whose Content-Length handling differs from Tinyproxy's, and the impact value is bounded by what the backend trusts the proxy for (cache contents, IP-based ACLs, header-stamped identity), so pure stateless backends derive less benefit for the attacker.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N) and the 9.3 base score reflect that exploitation requires only an attacker-reachable Tinyproxy instance and crafted HTTP traffic, with no authentication, user interaction, or unusual conditions. EPSS and CISA KEV data are not provided in the input, so real-world exploitation prevalence cannot be confirmed; the issue is currently rated 'no public exploit identified at time of analysis,' though the patch diff itself reveals the smuggling primitive and request smuggling exploitation against proxies is well understood in the offensive community. Practical risk is highest where Tinyproxy fronts shared caches, authentication gateways, or microservice backends - environments where smuggled requests translate directly into cache poisoning or auth bypass - and somewhat lower for pure outbound NAT-style proxy use cases.

An attacker who can reach a vulnerable Tinyproxy instance - for example, an internal user, a tenant on a shared proxy, or any client of an exposed forward proxy - sends a single TCP request containing two Content-Length headers with differing values plus a smuggled second request hidden in the body. Tinyproxy uses the first Content-Length to determine body length and forwards both headers to the backend, which uses the second value, causing the backend to interpret the trailing bytes as a new request attributed to the next legitimate client. The attacker leverages this desync to poison cached responses, bypass proxy-level authentication or ACLs, or hijack other users' in-flight requests.