CVE-2026-54388: Tinyproxy Auth Bypass Vulnerability

CVE-2026-54388 Overview

CVE-2026-54388 is an HTTP request smuggling vulnerability in Tinyproxy through version 1.11.3. The proxy fails to reject requests containing multiple Content-Length headers with differing values. It forwards all duplicate headers to the backend while using the first value to determine how many request body bytes to consume. This parser desynchronization between the proxy and backend allows remote attackers to inject arbitrary HTTP requests, enabling cache poisoning, access control bypass, and request hijacking. The flaw is fixed in commit 364cdb6 and is tracked under [CWE-444] Inconsistent Interpretation of HTTP Requests.

Critical Impact
Unauthenticated network attackers can desynchronize Tinyproxy and its backend to smuggle arbitrary HTTP requests, bypass access controls, and poison shared caches.

Affected Products

Tinyproxy versions up to and including 1.11.3
Deployments using Tinyproxy as a forwarding HTTP proxy in front of backend services
Builds prior to upstream commit 364cdb67e0ea00a8e4a7037e2693e0711e816adb

Discovery Timeline

2026-06-17 - CVE-2026-54388 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-54388

Vulnerability Analysis

The vulnerability is a classic HTTP request smuggling condition caused by inconsistent parsing of Content-Length headers between Tinyproxy and the backend server it forwards to. RFC 7230 requires that a message containing multiple Content-Length header fields with differing values must be rejected. Tinyproxy does not enforce this requirement.

When a client sends a request containing two or more Content-Length headers with different values, Tinyproxy uses the first value to determine how many body bytes to read from the client. It then forwards the entire request, including all duplicate Content-Length headers, to the backend. If the backend honors a different value, such as the last header, the two parsers disagree on where the first request ends and the next begins.

The attacker controls the trailing bytes of the smuggled request. Those bytes are parsed by the backend as a new, independent HTTP request from a trusted source. This enables injection of headers, methods, and URIs that bypass front-end controls.

Root Cause

The root cause is missing input validation in Tinyproxy's HTTP header parser. The parser accepts multiple Content-Length headers without comparing them or rejecting the request. The fix in commit 364cdb6 enforces rejection of requests containing duplicate or conflicting Content-Length headers, aligning behavior with RFC 7230 section 3.3.3.

Attack Vector

Exploitation is unauthenticated and remote over the network. An attacker submits a single TCP connection containing a crafted HTTP request with two Content-Length headers carrying different values. Tinyproxy consumes the body length specified by the first header and forwards the request. The backend processes the request using a different length and treats the residual bytes as a second pipelined request. The smuggled request can target internal endpoints, poison shared HTTP caches, or hijack the next legitimate user's request stream. Refer to the VulnCheck Advisory on Tinyproxy for additional technical context.

Detection Methods for CVE-2026-54388

Indicators of Compromise

HTTP requests arriving at Tinyproxy containing more than one Content-Length header in the same message
Backend access logs showing requests with methods, paths, or Host headers that the front-end proxy did not log
Cache entries serving responses that do not match the originally requested resource
Unexpected 5xx errors or connection resets correlated with malformed length headers

Detection Strategies

Inspect raw HTTP traffic to Tinyproxy listeners and flag any message containing duplicate Content-Length headers
Compare front-end proxy access logs against backend application logs to identify requests that appear only on the backend
Apply intrusion detection signatures for the byte pattern Content-Length: appearing more than once in a single request

Monitoring Recommendations

Enable verbose request logging on both Tinyproxy and the upstream backend to support log correlation
Alert on anomalous spikes in pipelined requests or short-lived connections carrying multiple HTTP transactions
Monitor cache hit anomalies and unauthorized access to administrative or internal-only URIs reachable through the proxy

How to Mitigate CVE-2026-54388

Immediate Actions Required

Upgrade Tinyproxy to a build that includes commit 364cdb6 or later
Inventory all Tinyproxy instances and confirm the running version against 1.11.3 and earlier
Place a strict HTTP-aware reverse proxy or web application firewall in front of Tinyproxy until patching is complete
Review backend logs for evidence of smuggled requests targeting sensitive endpoints

Patch Information

The upstream fix is committed to the Tinyproxy repository as 364cdb67e0ea00a8e4a7037e2693e0711e816adb. The change enforces rejection of HTTP requests containing multiple Content-Length headers. See the GitHub Commit on Tinyproxy, GitHub Issue #609 for Tinyproxy, and GitHub Pull Request #610 for the full patch context. Rebuild Tinyproxy from source against the patched tree or install distribution packages that incorporate the commit.

Workarounds

Front Tinyproxy with a hardened reverse proxy that rejects requests carrying duplicate Content-Length headers
Restrict network access to Tinyproxy to trusted client ranges using firewall rules or Allow directives in tinyproxy.conf
Disable HTTP keep-alive on the backend to limit the blast radius of pipelined smuggled requests where feasible

bash

# Configuration example: restrict Tinyproxy clients while patching is staged
# /etc/tinyproxy/tinyproxy.conf
Listen 127.0.0.1
Port 8888
Allow 10.0.0.0/8
DisableViaHeader Yes
MaxClients 100
# After upgrade, verify the binary includes commit 364cdb6
tinyproxy -v