OpenWrt uhttpd EUVD-2026-114522

Requires the ubus endpoint to be enabled and the /ubus URL reachable - this is the default in standard OpenWrt deployments. The attacker sends a POST /ubus with Content-Type: application/json and a Content-Length spanning a '{}' prefix plus a smuggled HTTP request suffix, and must control TCP segmentation so the '{}' completes in one segment and the remainder arrives in a later segment on a keep-alive connection; this segmentation is trivially controllable by a direct attacker. No authentication is required (PR:N) and no user interaction is needed. Limiting factors: the flaw only materially crosses a security boundary when uhttpd is behind a reverse proxy or CDN that reuses the connection - against uhttpd directly the smuggled request is processed as the attacker's own with little gain; ubus must be enabled (default); and the keep-alive connection must be reused. Updating to the patched repository commits is the fix stated by the vendor.

This is a genuine but moderate-priority issue, not an emergency. The CVSS 4.0 base is 6.9 (the GHSA independently estimates CVSS 3.1 ~5.9, medium), and the vuln.today Decision label is 'this_month' - meaning remediate within a normal patch window rather than immediately. The signals are internally consistent: attack vector is network (AV:N), complexity is low (AC:L - the attacker fully controls TCP segmentation and the ~100ms pause; this is not a race or an attacker-uncontrolled timing condition), no privileges (PR:N) and no user interaction (UI:N) are needed, but the technical impact is limited to request-integrity (CWE-444 HTTP request smuggling), with no confidentiality or availability impact in the supplied vector. No EPSS score and no CISA KEV entry are present in the input, so there is no evidence of active exploitation. A PoC reference exists - the GHSA documents exact reproduction steps and the reporter states they hold a complete ~130-line Python PoC - but it is attached to an email and is not verified as publicly available working exploit code. The real-world danger is amplified mainly when uhttpd sits behind a reverse proxy or CDN, where a smuggled request can cross a user/security boundary; against uhttpd directly the smuggled request is processed as the attacker's own and the impact is minimal. Note one data conflict to verify: the description states repository patch commits already address the issue, while the GHSA package field reads 'fixed in: not yet patched', implying the fix commits may not yet be in a tagged OpenWrt release - confirm release status with the vendor.

An attacker opens a keep-alive connection to a uhttpd instance with ubus enabled and sends a POST /ubus request whose Content-Length covers both a complete '{}' JSON object and a trailing smuggled 'GET / HTTP/1.1' request. They deliver the '{}' in the first TCP segment, pause ~100ms, then send the remainder; uhttpd emits a JSON-RPC parse error, consumes zero further bytes, fails to drain the body or close the connection, and processes the smuggled suffix as a second HTTP request. Reproduction steps are documented publicly in the GHSA and the reporter states a full PoC script exists, though it is not published; impact is greatest when uhttpd is fronted by a reverse proxy or CDN.