CVE-2026-77630 in pupnp
Summary
by MITRE • 10/16/2026
pupnp is an SDK for development of UPnP device and control point applications. Prior to 22.0.4, parse_hostport in upnp/src/genlib/net/uri/uri.c synchronously calls getaddrinfo while parse_uri is processing attacker-supplied hostnames from inbound HTTP request targets in upnp/src/genlib/net/http/httpparser.c and GENA SUBSCRIBE CALLBACK headers handled by create_url_list in upnp/src/gena/gena_device.c. A remote unauthenticated peer can choose a slow or nonresponsive hostname and block a bounded miniserver worker for the resolver timeout, allowing a small number of requests to exhaust the thread pool and deny UPnP service. This issue is fixed in 22.0.4.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The Universal Plug and Play (UPnP) protocol suite provides a framework for devices to discover each other on a local network and establish functional network services, such as port forwarding or media streaming. The Portable UPnP SDK serves as a foundational library enabling developers to build compliant UPnP devices and control points. Within this ecosystem, the miniserver component acts as the core HTTP server handling incoming requests from clients seeking service discovery or device management actions. A critical architectural flaw exists in how the SDK processes network addresses during these interactions, specifically within the URI parsing logic that translates user-supplied input into actionable connection parameters.
The vulnerability stems from a synchronous DNS resolution mechanism embedded deep within the request processing pipeline. When an inbound HTTP request target is processed by the httpparser component or when GENA SUBSCRIBE CALLBACK headers are handled via create_url_list, the system invokes parse_uri which subsequently calls parse_hostport. This function triggers getaddrinfo to resolve hostnames into IP addresses before any further validation or connection establishment occurs. Because this resolution happens synchronously within the main worker thread of the miniserver, the thread is blocked until the DNS resolver returns a result or times out. An attacker can exploit this by supplying hostnames that are deliberately slow to respond or completely non-responsive, such as domains configured with extremely long Time-To-Live values pointing to unreachable addresses or using DNS configurations designed to maximize lookup latency.
This design flaw creates a straightforward path for a Denial of Service attack against UPnP services. Since the miniserver utilizes a bounded thread pool to handle concurrent connections, each malicious request that triggers a slow DNS resolution consumes one worker thread for an extended period. A remote unauthenticated peer can send a small number of such requests to exhaust all available threads in the pool. Once the thread pool is saturated, legitimate UPnP clients are unable to obtain service discovery responses or manage device configurations, effectively rendering the UPnP functionality unavailable on the affected system. This impact is particularly severe because it requires no authentication and leverages standard network protocols that are often exposed to local networks without strict access controls.
From a classification perspective, this vulnerability aligns with CWE-400, which covers Uncontrolled Resource Consumption, specifically manifesting as resource exhaustion through thread blocking. It also relates to CWE-770, Allocation of Resources Without Limits or Throttling, as the system fails to limit the time resources are held during DNS resolution operations. In terms of offensive security frameworks, this technique corresponds to MITRE ATT&CK T1496, Resource Hijacking, where an attacker consumes computational resources to degrade service availability for legitimate users. The attack vector is classified under Network-Based exploitation with no required user interaction beyond sending crafted network packets.
Mitigation strategies primarily involve upgrading the Portable UPnP SDK to version 22.0.4 or later, which addresses this issue by modifying the DNS resolution behavior to prevent blocking worker threads indefinitely. For systems where an immediate upgrade is not feasible, defensive measures should include implementing strict rate limiting on inbound HTTP requests and GENA subscriptions from untrusted sources. Additionally, deploying network-level controls such as firewall rules that restrict UPnP traffic to only known, trusted IP subnets can significantly reduce the attack surface. Organizations relying on UPnP for critical infrastructure or public-facing services should consider disabling unnecessary UPnP functionality entirely if it is not strictly required, thereby eliminating this vector of denial-of-service attacks altogether.