uhttpd: HTTP request smuggling via ubus POST body parse-error desync
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Default setups
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
uhttpd, a small HTTP server commonly used on OpenWrt routers, is affected when its ubus interface handles POST /ubus requests whose JSON body arrives split across multiple TCP segments. An attacker can exploit the resulting request boundary desync to smuggle a second HTTP request onto a keep-alive connection, potentially bypassing front-end proxy or CDN controls.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
uhttpd is a small HTTP server. In unpatched repository snapshots, `uh_ubus_data_send()` in `ubus.c` can desynchronize HTTP request boundaries when a `POST /ubus` JSON body arrives in multiple TCP segments. An initial segment completing a JSON object sets `du->jsobj`; a later segment takes the existing-object parse-error path and returns zero bytes consumed. The caller neither drains the remaining declared `Content-Length` nor sets `connection_close`. An HTTP request embedded in the unread body suffix is consequently processed as a new request on the same keep-alive connection. The reported reproducer returned a JSON-RPC parse error followed by a second HTTP response. This application-layer body-handler flaw is distinct from Transfer-Encoding header case handling and chunk-length state reset, and affects deployments enabling ubus, including the default OpenWrt configuration and potential proxy/CDN deployments. Repository patches 7b1bec45826bd78c8afc993435bdc0f1df2fe399 and b2285de129b9adc8b12f84f9a27c16c21f2b57a5 address this issue.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- openwrt uhttpd
Version range not reported
References 3
GitHub · openwrt/uhttpd
Questions about CVE-2026-55613
What does this mean?
When a POST to uhttpd's /ubus endpoint delivers its body in several TCP segments, the first fragment can complete a JSON object. A later fragment then hits the parse-error path, which can desynchronize how the request is handled. The advisory titles this as HTTP request smuggling.Source: github.com
Am I affected, and how do I check?
The checked facts list no affected version ranges. The trigger is a POST to /ubus whose body arrives in multiple TCP segments, with the first fragment completing a JSON object. To check a device, look at the installed uhttpd package version and compare it against the advisory's version list.Source: github.com
What should I do about it?
The checked facts name no fixed release, so no upgrade target can be given from them. Check the upstream OpenWrt advisory for a patched uhttpd version and update to it once published.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What if there's no patch?
The checked facts give no workaround. The only documented trigger is the multi-segment POST to /ubus, so the advisory and upstream sources are the place to look for mitigations until a fix is available.Source: github.com