MiniUPnPd and UPnP vulnerabilities in embedded firmware: find, triage and fix

Because UPnP was designed for a trusted LAN and has no authentication, but it runs on the device that sits between the LAN and the Internet. The CERT/CC note on CallStranger puts it plainly: the protocol "is designed to be used in a trusted local area network (LAN) and the protocol does not implement any form of authentication or verification." On a router, the UPnP Internet Gateway Device (IGD) service exists to open port forwards in the firewall on request, so any LAN client, or any web page a LAN client visits, can ask for one.

Two kinds of exposure follow. The first is a parser problem: SSDP listens on UDP port 1900 and the control and eventing endpoints take HTTP and SOAP from the network, so a memory-safety bug in either is remotely reachable without credentials. The second is a deployment problem. CERT/CC's older VU#357851 describes routers that "incorrectly accept UPnP requests over the WAN interface", where AddPortMapping and DeletePortMapping let a remote attacker reach internal hosts or proxy traffic through the device. The MiniUPnP project's own home page names the same mistake: "A common problem is to let SSDP or HTTP/SOAP ports open to the internet : they should be only reachable from the LAN."

Three families cover most images:

The MiniUPnP home page describes the daemon as using "only ONE process and no additional thread" and no system() or exec() call, which is one reason it suits low-memory routers. libupnp has a different lineage: CERT/CC's VU#922681 traces it to Intel's Linux SDK for UPnP Devices and notes that "many different vendors produce UPnP-enabled devices that use libupnp." Vendor stacks are the hardest case, because their version strings rarely map to any public changelog.

Group findings by class first, because the class tells you where the bug is reachable from and which mitigation works.

"Secondary only" means NVD lists a score from the CVE source but has published no Primary score of its own. Scores were read from NVD on 2026-11-13.

SSDP parsing and SSDP reflection. SSDP is the most exposed surface, because it is UDP and needs no session. The 2012 libupnp set was found by Rapid7 during a scan of Internet-facing UPnP devices; VU#922681 says Portable SDK versions 1.2.1a to 1.8.0 carry "at least three remotely exploitable buffer overflows in the unique_service_name() function, which is called to process incoming SSDP requests on UDP port 1900", and that 1.6.18 fixes them. Even a correct SSDP responder is a problem when it answers the Internet: it becomes a reflector. In its analysis of a 100 Gbps SSDP attack, Cloudflare measured "7x packet number amplification" and "20x bandwidth amplification" for an ssdp:all M-SEARCH, and put the open reflectors down to a firewall misconfiguration: "port 1900 UDP open to the world". No CVE covers that: it is a configuration defect, and the fix is to never answer M-SEARCH from WAN.

CallStranger and SUBSCRIBE abuse. UPnP eventing lets a control point send SUBSCRIBE with a CALLBACK header naming where event messages go. Before 2020, the specification did not require that address to be local, so, per CERT/CC, an attacker could "send large amounts of data to arbitrary destinations accessible over the Internet", for DDoS or data exfiltration. The Open Connectivity Foundation's UPnP Device Architecture 2.0 revision of 17 April 2020 now states that "the subscription request containing a delivery URL not on the same network segment as the fully qualified event subscription URL shall not be accepted." The SUBSCRIBE handler is also a code path in its own right: CVE-2016-8863 is a heap overflow in libupnp's CALLBACK parser, and the KEV-listed CVE-2019-17621 is command execution through a SUBSCRIBE request to D-Link's gena.cgi. Our hostapd and wpa_supplicant guide covers the CallStranger fix in hostapd's WPS UPnP code, a fourth UPnP stack that many access points carry.

SOAP and HTTP parsing. Control actions such as AddPortMapping arrive as SOAP over HTTP. CVE-2013-0230 is a stack overflow in MiniUPnPd 1.0 from "a long quoted method" in the SOAPAction header, and the vendor CVE-2014-8361 lets a crafted NewInternalClient value reach a shell in Realtek's miniigd. The second is exploited: CISA added it to KEV on 2023-09-18, and the NVD description says it was "exploited in the wild through 2023." For the code-level fixes behind these classes, see our guides on fixing memory corruption and fixing command injection in embedded firmware.

MiniUPnPd. There is no separate advisory page. Fixes appear as dated entries in the MiniUPnPd Changelog, grouped under each release, and release tarballs are listed on miniupnp.free.fr. The latest release on 2026-11-13 is 2.3.11, of 12 August 2026. Entries made after it include "MX: 0 in SSDP is invalid. fixes CVE-2026-107159" (3 October 2026) and "enforce Content-Length / header limit on HTTP receive" (29 August 2026), so a device that needs those fixes must take the commits from the source tree until the next tagged release. Read the dated entries, not only the version headings: 2.3.4 enabled secure mode by default and disabled the DeviceProtection service by default, and 2.3.11 fixed a heap overflow in PinholeVerification(). The MiniUPnP home page adds that "several vulnerabilities have been found in MiniUPnPd, so it is very important to update your code to the last version."

libupnp (pupnp). The project publishes GitHub security advisories with an affected range and a patched version each, and lists the fixes in release notes. Activity in 2026 has been heavy: release 22.2.2 of 9 November 2026 is the latest, and the advisory list shows more than 25 advisories published between April and November 2026, many of them for pre-authentication denial of service and out-of-bounds reads in SSDP, GENA, HTTP and XML parsing. Only some carry CVE numbers, such as CVE-2026-57487 (chunked bodies bypassing the content-length limit, fixed in 2.0.2), so a CVE-only feed under-reports them. The security policy marks only the current release line as supported. Older lines receive occasional fixes, for example 1.14.31 in April 2026 for CVE-2026-41682, but a device on 1.6.x or 1.8.x should be treated as unsupported.

Vendor stacks. Fixes come from the SoC or device vendor only. For CVE-2014-8361, CISA's KEV entry points to a D-Link advisory rather than a Realtek one, which shows how far the fix trail can be from the code's origin. If your SDK supplier ships an IGD daemon, ask for its version history and fix list in writing.

Rank by exposure first: is the daemon reachable from WAN, from the LAN only, or not running? Then by exploitation data, then by CVSS. Data as of 2026-11-12 (CISA KEV catalog version 2026.11.10, FIRST EPSS scores dated 2026-11-12):

Two things stand out. The KEV-listed UPnP flaws are all in vendor stacks, not in MiniUPnPd or libupnp, so a component list that only shows open-source packages can miss the most exploited code on the device. And the EPSS scores for old libupnp and MiniUPnPd CVEs stay high a decade on, because those versions remain on the Internet. Our KEV and EPSS prioritisation guide explains how the two signals combine.

Upgrade or backport, close the WAN side, tighten the LAN side, then rebuild and prove it.

Upgrade or backport. Move MiniUPnPd to 2.3.11 and apply the later source fixes you need, such as the CVE-2026-107159 commit if you build with --strict. Move libupnp to the current pupnp release; from 1.6.x or 1.8.x that is a large API jump, so budget for it. For a vendor daemon, get the fixed build from the supplier or replace the daemon with a maintained one.

Close the WAN side. Each of these removes a whole class from Internet reach:

CERT/CC's CallStranger note asks device makers to "disable the UPnP SUBSCRIBE capability in their default configuration" and to require users to enable it explicitly for the trusted LAN. OpenWrt's default miniupnpd configuration is a good reference: enabled is 0, secure_mode is 1, and the permission rules allow only ports 1024 to 65535 and end with a default deny. Zyxel's statement in the CERT/CC note gives the WAN-side argument: its affected product had a default firewall rule blocking UPnP from WAN, so the risk arose only if users disabled the firewall.

Tighten the LAN side. Keep secure mode on, so a client can map ports only to its own address. Restrict permission rules to ports 1024 and above. Leave the DeviceProtection service and IPv6 pinholes off unless the product uses them.

Rebuild, re-scan, release. Regenerate the firmware SBOM, compare it with the previous release using firmware diffing, and run a WAN-side SSDP and HTTP test against the new build. Publish the fix with affected versions, fixed version and the CVE list; where a CVE does not apply because UPnP is not compiled in or never listens on WAN, record that in a VEX statement as our CSAF and VEX for device makers guide shows. The same image usually also ships dnsmasq, BusyBox and Dropbear; see our guides on dnsmasq vulnerabilities, BusyBox vulnerabilities and Dropbear SSH vulnerabilities.

SoftWSP's automated scan unpacks a firmware image, catalogs the software components in the extracted file system, and records each one with its version, so a miniupnpd or libupnp package recorded in the opkg or other package database appears in the component list. It then matches component versions against CVE records, CISA's KEV catalog and FIRST's EPSS scores. This is deterministic code: the code scores, and AI narrates.

AI's part is the written explanation on top of that matching. It summarises which UPnP-related CVEs matched, which are KEV-listed or have a high EPSS score, and what version evidence supports each match, and every sentence cites the component, version and record it relies on. An engineer reviews every finding before the report is delivered. Several judgements in this guide stay with that engineer: recognising a vendor daemon such as miniigd from its strings when no package record names it, confirming that a component maps to the right NVD product, reading the build options and configuration, and testing whether UPnP answers on WAN. Those are the steps that turn a version match into an "affected" or "not affected" decision.

For where UPnP review fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the MiniUPnPd Changelog, example configuration and source code, the MiniUPnP home page, pupnp's release notes, security advisories and security policy, CERT/CC notes VU#339275, VU#922681 and VU#357851, the Open Connectivity Foundation's UPnP Device Architecture 2.0, Cloudflare's SSDP measurement, OpenWrt's miniupnpd package, NVD, CISA's KEV catalog (version 2026.11.10) and FIRST EPSS data dated 2026-11-12, all read directly on 2026-11-13.