CVE-2026-57487 in pupnp
Summary
by MITRE • 10/16/2026
pupnp is an SDK for development of UPnP device and control point applications. Prior to 2.0.2, Transfer-Encoding: chunked causes the HTTP parser in upnp/src/genlib/net/http/httpparser.c to leave parser->content_length at zero while parser_parse_chunky_entity and parser_parse_chunky_body accumulate decoded bytes in parser->msg.entity. The g_maxContentLength checks in http_RecvMessage in upnp/src/genlib/net/http/httpreadwrite.c therefore reject oversized numeric Content-Length bodies but do not enforce the same limit on decoded chunked bodies. A remote peer that can reach a SOAP, GENA, miniserver, or control-point HTTP response path can make the process buffer an entity larger than the configured maximum, causing resource exhaustion and denial of service. This issue is fixed in 2.0.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The Universal Plug and Play (UPnP) protocol suite relies on a robust software development kit to facilitate communication between networked devices and control points. Within this ecosystem, the HTTP parser plays a critical role in processing incoming messages for SOAP, GENA, miniserver, and control-point interactions. A significant architectural flaw exists in versions of the UPnP SDK prior to 2.0.2 regarding how chunked transfer encoding is handled compared to standard content-length based bodies. This discrepancy creates an opportunity for remote attackers to exploit memory management logic within the HTTP parsing engine, leading to severe resource exhaustion and denial of service conditions.
The core technical vulnerability stems from a failure in boundary enforcement during the parsing of HTTP messages that utilize Transfer-Encoding: chunked. When the parser processes such entities via functions like parser_parse_chunky_entity and parser_parse_chunky_body, it accumulates decoded bytes into the message entity buffer without updating the content_length field, which remains at zero. Consequently, subsequent validation logic in http_RecvMessage fails to apply the configured g_maxContentLength limit to these chunked bodies. While oversized numeric Content-Length headers are correctly rejected by existing checks, this safeguard is bypassed entirely for chunked transfers because the parser does not track the accumulated size against the maximum allowed threshold during the decoding process.
This logic error allows a remote peer with network access to an affected UPnP service endpoint to craft malicious HTTP responses containing excessively large chunked entities. As the vulnerable application processes these messages, it continues to allocate memory for the entity buffer without restriction until system resources are depleted or the allocation fails catastrophically. The operational impact is a denial of service where the target process may crash, hang, or consume excessive CPU and memory resources, thereby disrupting legitimate UPnP discovery and control operations across the local network segment.
From a classification perspective, this vulnerability aligns with CWE-400 Uncontrolled Resource Consumption as it involves failing to limit resource usage based on external input size. It also relates to CWE-20 Improper Input Validation since the application does not adequately validate or constrain data received from upstream sources before processing. In terms of attack vectors, this falls under ATT&CK technique T1498 Network Denial of Service, specifically involving direct network-based resource exhaustion through malformed protocol messages that exploit implementation-specific parsing flaws rather than generic buffer overflows.
Mitigation strategies primarily involve upgrading the UPnP SDK to version 2.0.2 or later where the parser logic has been corrected to enforce content length limits on chunked transfers equivalent to those applied to standard bodies. For environments unable to immediately patch, network-level controls such as deep packet inspection firewalls can be configured to drop HTTP responses with excessively large chunked payloads before they reach the vulnerable UPnP services. Additionally, implementing strict rate limiting and connection timeouts for SOAP and GENA endpoints can help mitigate the impact of resource exhaustion attacks by preventing a single malicious session from monopolizing system resources indefinitely.