Transfer-Encoding case mismatch desyncs Tinyproxy, risking backend DoS

TL;DR — Tinyproxy’s case-sensitive Transfer-Encoding parsing can desynchronize HTTP request framing, enabling unauthenticated backend connection hangs (DoS) and potential request-body inspection bypass.

What happened

Tinyproxy is a lightweight HTTP/HTTPS proxy commonly used to forward requests to upstream application servers. CVE-2026-31842 describes an HTTP request parsing desynchronization bug where Tinyproxy compares the Transfer-Encoding header value to the string "chunked" in a case-sensitive way.

Per the CVE record, a request containing Transfer-Encoding: Chunked can cause Tinyproxy to mis-handle request body framing: it forwards request headers upstream and transitions into raw TCP relay mode while unread body data remains buffered. RFC-compliant backends (the CVE calls out Node.js and Nginx as examples) may continue waiting for chunked body data, leading to stalled connections and application-level DoS via worker exhaustion. The CVE also notes that in deployments using Tinyproxy for request-body inspection/filtering, this can create a security control bypass where unread body data may be forwarded without proper inspection.

Request framing/canonicalization drift is a recurring root cause for desync and request smuggling classes of issues; this one is especially operationally painful because it can be triggered unauthenticated and can tie up backend capacity without “obvious” exploit payloads.

Who is impacted

• Any deployment running Tinyproxy versions reported as affected in the CVE record (<= 1.11.3).
• Internet-exposed or untrusted-network Tinyproxy instances (the CVSS vectors indicate network reachability).
• Environments that rely on Tinyproxy for request-body parsing, inspection, filtering, or security enforcement, where a parsing bypass can undermine upstream policy controls.
• Backends with limited connection/worker pools, where hung requests can rapidly exhaust capacity (availability impact is High in both CVSS v4.0 and v3.1 in the CVE record).

What to do now

• Follow upstream/vendor remediation guidance as it becomes available, and track the linked upstream issue referenced by the CVE for status and reproduction details.
• Inventory where Tinyproxy is deployed (system packages, containers, and base images) and prioritize any instances that proxy traffic from untrusted clients.
• Reduce exposure and blast radius while assessing fixes:
  • place Tinyproxy behind a trusted reverse proxy / gateway where you can enforce stricter HTTP normalization
  • apply conservative timeouts and connection limits on backends to reduce “hung connection” worker exhaustion risk
• If you depend on Tinyproxy for body inspection/enforcement, treat this as a potential “inspection gap” class bug:
  • validate whether your enforcement point actually sees and parses request bodies under desync conditions
  • add compensating controls at a layer that fully parses/normalizes HTTP semantics before policy evaluation
• If you suspect abuse, review proxy and backend logs for hanging requests correlated with mixed-case Transfer-Encoding values and unusual upstream connection utilization patterns.