pupnp CVE-2026-57488

Exploitation requires: (1) network reachability to a pupnp/libupnp HTTP endpoint from the adjacent/link-local segment (AV:A - UPnP is LAN-facing, not internet-exposed by default); (2) the target compiled on an LP64 system where long is 64-bit and int is 32-bit, so a Content-Length exceeding INT_MAX truncates or wraps in raw_to_int - on ILP32/32-bit builds the truncation condition does not arise the same way; and (3) for the request-smuggling impact specifically, a persistent (keep-alive) or proxied HTTP context where leftover bytes are reinterpreted as a subsequent request. The denial-of-service path is less constrained: a single oversized Content-Length can make a worker wait for a body that never arrives. No authentication is required (PR:N) and no user interaction (UI:N); the primary limiting factors are the adjacent-network reach and the 64-bit build precondition. Affected versions are prior to 2.0.2; the fix is 2.0.2.

This is a genuine but moderate-priority issue, best treated as an environment-dependent risk rather than an urgent fix. The CVSS 3.1 vector (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H, 7.1 High) indicates an adjacent-network, low-complexity, unauthenticated attack with no confidentiality loss, limited integrity impact (I:L, consistent with request-smuggling-style parser disagreement) and high availability impact (A:H, consistent with the worker-hang denial-of-service path). The AV:A restriction to the adjacent/link-local segment is significant and realistic for pupnp, since UPnP is a LAN-facing protocol - this is not an internet-wide remotely exploitable flaw by default. No EPSS score, no CISA KEV listing, and no public POC were provided; the only source-code artifact is the vendor patch commit, which is a fix and not an exploit. The signals therefore align rather than conflict: a moderate-severity, hard-to-reach-from-the-internet bug with no evidence of active exploitation, best described as no public exploit identified at time of analysis. One caveat defenders should verify: the integer-truncation behavior requires an LP64 (64-bit long, 32-bit int) build, so 32-bit/ILP32 targets may not be affected the same way - confirm the build platform before assuming exposure.

An attacker on the same LAN/adjacent network segment as a pupnp-based UPnP service (e.g. a router, NAS, or media device) sends an HTTP request with a Content-Length greater than INT_MAX. On a 64-bit (LP64) build the value truncates/wraps, so the parser accepts a body length differing from the declared value; in a persistent or proxied connection this leaves leftover bytes to be interpreted as a second smuggled request, or alternatively the worker blocks waiting for an enormous body and the service is denied. No public exploit code was identified at time of analysis.