CVE-2026-73257

CVE-2026-73257 is a HTTP request smuggling vulnerability in Mongoose HTTP server library where the parser's leniency with ambiguous headers — accepting both Content-Length and Transfer-Encoding with chunked taking priority — creates a desynchronization opportunity when Mongoose sits behind a Content-Length-preferring reverse proxy. This is not a typical bug; it's a design failure that emerged from reasonable-seeming flexibility that became dangerous in composition with other components. The core issue: Mongoose consumes the chunked body entirely based on Transfer-Encoding, but a downstream CL-preferring proxy interprets the remaining bytes as a new request. The request boundary disagreement means one user's request body gets appended to another user's request — a cross-tenant injection with no logging trail. This is the CL.TE desync vector, well-documented since 2005, but it survived into a 2026 release because the library's embedded context creates a false expectation of safety. Developers using Mongoose have opted for simplicity; they likely never modeled what happens when their application sits behind a reverse proxy they don't control. The fix in version 7.22 presumably tightens parsing to reject ambiguous headers. This raises a backward-compatibility question that defenders must answer: which legitimate clients were actually sending both headers and relying on Mongoose's leniency? In embedded IoT and legacy industrial deployments — contexts where Mongoose sees heavy use — this is a real concern. The vulnerability class simply shifts upstream: instead of cross-user desynchronization, you may now get client-library desynchronization if clients send ambiguous requests that 7.22 rejects. What to check: audit your deployment topology. If Mongoose sits behind any reverse proxy, verify the proxy's header precedence handling and ensure both components agree on request boundaries. The standard HTTP client libraries your test suite uses never fuzz ambiguous headers — they generate compliant requests — so standard testing won't catch this. You need to model a hostile intermediary, which means explicitly testing with requests that contain both Content-Length and Transfer-Encoding headers. If you're on a version before 7.22 and cannot upgrade immediately, ensure your upstream proxy strictly validates header consistency or disable chunked transfer encoding at the proxy layer. The risk of keeping the old behavior is unbounded cross-tenant injection; the risk of the fix is breaking clients that were sending genuinely ambiguous requests — these are not equivalent blast radiuses.

Reviewed through automated stages and approved by a human before publication.