pupnp (libupnp) EUVD-2026-102933

Exploitation requires that the target run the pupnp (libupnp) miniserver with network reachability to its HTTP/GENA listener, and that the attacker can reach the inbound HTTP request path or send GENA SUBSCRIBE requests carrying a CALLBACK header - both parsed by parse_uri/parse_hostport, which synchronously resolves the attacker-supplied hostname via getaddrinfo. No authentication or user interaction is needed (PR:N/UI:N), and default configurations are affected because the resolver call occurs during normal request parsing. The decisive attacker-controlled condition is supplying a hostname (not a literal IP) that resolves slowly or not at all, maximizing time each worker is blocked. The primary LIMITING factor is reachability: UPnP miniservers are usually bound to the local network, so practical exploitation presumes LAN access (or a device misconfigured to expose UPnP to the internet); impact is also self-limiting and recoverable once requests stop and threads free.

This is a genuine but bounded availability issue, not a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 HIGH) is internally consistent with the description: a remote, unauthenticated peer sends inbound HTTP request targets or GENA SUBSCRIBE CALLBACK headers containing attacker-chosen hostnames, and pupnp's parse_hostport synchronously calls getaddrinfo, blocking a bounded miniserver worker for the full resolver timeout; a handful of such requests exhaust the thread pool and deny UPnP service. Impact is purely availability (C:N/I:N) - there is no code execution or data exposure, so despite the HIGH rating this is a classic CWE-400 resource-exhaustion DoS rather than a critical breach vector. No EPSS score was supplied, and the issue is NOT in CISA KEV, so there is no evidence of active exploitation. The oss-fuzz issue reference (issues.oss-fuzz.com/531780528) indicates the defect was found by fuzzing and that a reproducer likely exists internally, but that is a triage artifact, not a published weaponized exploit, so exploitation status is best read as 'no public exploit identified at time of analysis.' A key real-world mitigant the raw score does not capture: UPnP miniservers are typically bound to the LAN, so AV:N holds only where the attacker already has local-network reachability (or the device is misconfigured to expose UPnP to the internet). Net: real and worth patching for anyone embedding libupnp, but a predictable, recoverable DoS on a LAN-facing service, not a widespread remote-compromise priority.

An attacker with network reachability to a device running the pupnp miniserver sends a small number of crafted HTTP requests (or GENA SUBSCRIBE requests) whose request-target or CALLBACK header names a deliberately slow or non-responsive hostname. Each request pins a miniserver worker thread inside a synchronous getaddrinfo call for the resolver timeout, and because the thread pool is bounded, only a few concurrent requests are needed to tie up all workers and make the UPnP service unresponsive. No public exploit is identified, though the flaw was surfaced via oss-fuzz fuzzing.