Tinyproxy through 1.11.3

CVE-2026-54387 is a classic CL/TE HTTP request smuggling flaw in Tinyproxy through version 1.11.3. When a client sends a request containing both a Content-Length header and a Transfer-Encoding: chunked header, Tinyproxy uses the Content-Length value to decide how many body bytes to consume, then forwards both headers verbatim to the backend. Any RFC 7230-compliant backend will prioritize Transfer-Encoding, creating a desynchronization: the proxy thinks it forwarded one request; the backend sees two. This lets a remote, unauthenticated attacker inject arbitrary HTTP requests into the backend pipeline — enabling cache poisoning, access-control bypass, and session hijacking. All versions through 1.11.3 are affected; the fix is commit ff45d3b.

The vendor-assigned CVSS 9.1 CRITICAL is *technically defensible* on the vector math — unauthenticated, network-reachable, no user interaction, high confidentiality and integrity impact. But for an enterprise fleet manager, it overstates the real-world risk. Tinyproxy is a lightweight, embedded-class proxy with a small enterprise footprint; most 10,000-host environments either don't run it at all or confine it to containers and lab segments. The impact caps at request smuggling — serious, but not remote code execution. With no KEV listing, no confirmed in-the-wild exploitation, and an EPSS of 0.44%, the operational urgency is HIGH, not CRITICAL.

Why this verdict

• Unauthenticated, zero-click, network-reachable — the CVSS attack vector is accurate and keeps the floor above MEDIUM. No credentials or user interaction needed; anyone who can reach the proxy port can attempt smuggling.
• Trivial weaponization — CL/TE smuggling is a textbook technique with mature tooling (PortSwigger smuggler, smuggler.py). A competent attacker needs minutes, not days, to craft a working payload against a known-vulnerable proxy.
• Limited enterprise footprint narrows real exposure — Tinyproxy is a lightweight, embedded-class proxy. Enterprise fleets overwhelmingly use Squid, NGINX, HAProxy, or commercial alternatives. The ~90K internet-facing instances skew heavily toward IoT/embedded devices, not managed enterprise infrastructure.
• Impact caps at HTTP-layer manipulation, not RCE — smuggling enables cache poisoning, session hijacking, and ACL bypass, but does not grant shell access or lateral movement beyond the HTTP pipeline. This bounds the blast radius to the proxy's user population.
• Role multiplier: Tinyproxy *can* serve as a network-edge forward proxy, placing it in the 'network edge appliance' high-value category. However, <10% of Tinyproxy installations occupy this role in enterprise contexts — the vast majority are embedded, containerized, or lab deployments. Where it IS the edge proxy for a multi-user environment, smuggling could compromise all sessions transiting it, keeping the floor at HIGH. But it is not a canonical high-value-role component like F5 BIG-IP or Citrix NetScaler, so the floor does not force CRITICAL.

Why not higher?

CRITICAL would require either active exploitation (KEV/campaign evidence), remote code execution, or a canonical high-value deployment role (≥10% of installs in identity/hypervisor/perimeter tier). Tinyproxy's enterprise footprint is too small to treat every instance as a critical-path component, and the impact ceiling is HTTP smuggling — not shell access or domain compromise. The low EPSS (0.44%) and absence of any in-the-wild activity further argue against CRITICAL urgency.

Why not lower?

The vulnerability is unauthenticated and network-reachable with zero user interaction — the most dangerous attack vector class. CL/TE smuggling is trivially weaponizable with off-the-shelf tools, and the impact (session hijacking, cache poisoning) is genuinely high-severity for any deployment where Tinyproxy fronts multiple users or a valuable backend. Dropping to MEDIUM would understate the risk for the subset of environments that do run Tinyproxy in a meaningful proxy role.

1. Deploy WAF rules to reject requests with both Content-Length and Transfer-Encoding headers — A WAF or reverse proxy upstream of Tinyproxy (e.g., ModSecurity, NGINX, AWS ALB) can normalize or reject ambiguous requests before they reach Tinyproxy. This directly blocks the CL/TE desync vector. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
2. Restrict Tinyproxy listener to localhost or internal-only interfaces — If Tinyproxy is used for outbound proxying (e.g., container egress), bind it to 127.0.0.1 or a private VLAN — never expose port 8888/8080 to untrusted networks. This eliminates the unauthenticated remote attack vector entirely. Review firewall rules within 30 days.
3. Apply commit ff45d3b from source or wait for distro package update — The fix is available in commit ff45d3bf0e61d0f8ed97ab379d3047f04eb67521. If your distro hasn't packaged it yet, build from source pinned to that commit or later. Target remediation within 180 days per the noisgate remediation SLA for HIGH.
4. Enable Tinyproxy access controls (Allow/Deny directives) — Limit which source IPs can connect to Tinyproxy using Allow directives in tinyproxy.conf. This reduces the attack surface to trusted clients only, though it doesn't fix the underlying parsing flaw.

Run this script on any host where Tinyproxy is installed. It checks the installed version and, if possible, the presence of the fix commit. No special privileges required. Example: bash check_cve_2026_54387.sh

#!/usr/bin/env bash
# check_cve_2026_54387.sh — Detect CVE-2026-54387 (Tinyproxy CL/TE smuggling)
# Run on any host with tinyproxy installed. No root required.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

TPBIN=$(command -v tinyproxy 2>/dev/null || true)

if [ -z "$TPBIN" ]; then
  echo "UNKNOWN — tinyproxy not found in PATH"
  exit 2
fi

VERSION=$($TPBIN -v 2>&1 | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not parse tinyproxy version"
  exit 2
fi

echo "Detected tinyproxy version: $VERSION"

# All versions through 1.11.3 are vulnerable.
# Compare version using sort -V
FIXED_VERSION="1.11.4"

if printf '%s\n%s\n' "$FIXED_VERSION" "$VERSION" | sort -V | head -1 | grep -qx "$FIXED_VERSION"; then
  echo "PATCHED — tinyproxy $VERSION is >= $FIXED_VERSION"
  exit 0
fi

# Version is <= 1.11.3, but distro may have backported the fix.
# Check if the binary contains the fix signature (reject CL+TE combo).
# This is a heuristic — check for the string pattern from the fix commit.
if strings "$TPBIN" 2>/dev/null | grep -qi 'transfer-encoding.*content-length\|reject.*conflicting'; then
  echo "PATCHED (heuristic) — binary appears to contain CL/TE fix backport"
  exit 0
fi

echo "VULNERABLE — tinyproxy $VERSION is affected by CVE-2026-54387 (all versions through 1.11.3)"
echo "Fix: apply commit ff45d3b or upgrade to >= 1.11.4 when released"
exit 1

Sources

1. SecurityOnline — Tinyproxy Request Smuggling Flaws Expose Networks
2. THREATINT — CVE-2026-54387
3. Black Kite — TPRM Insights: Tinyproxy
4. SANS @Risk Newsletter — June 25, 2026
5. PortSwigger — HTTP Request Smuggling
6. SecurityAffairs — Tinyproxy Censys Exposure Data
7. Debian Package Tracker — tinyproxy