Universal Plug and Play (UPnP) Protocol Detection is an informational Nessus finding (plugin 35711) raised when a device answers SSDP discovery requests on UDP port 1900. To fix it, turn off UPnP on routers, printers, NAS and cameras that do not need it, disable SSDP Discovery on Windows, and block UDP 1900 at network boundaries.

UPnP was built so home devices could find each other without configuration. On a managed network that becomes unauthenticated self-advertisement, and on a router it can mean unauthenticated port forwarding.

What the scanner is actually detecting

The finding comes from Tenable Nessus. This is what Tenable publishes for the plugin:

Field	Value
Plugin ID	35711
Title	Universal Plug and Play (UPnP) Protocol Detection
Severity	Info
Family	Service detection (remote, unauthenticated)
Port	UDP 1900 (SSDP)
Tenable solution	“Filter access to this port if desired.”

Nessus sends an SSDP M-SEARCH request to UDP 1900 and reports the host when a valid response comes back. SSDP (Simple Service Discovery Protocol) is the discovery layer of UPnP. A response normally carries a SERVER header naming the operating system or firmware and the UPnP stack, and a LOCATION header pointing to an HTTP URL where the device publishes an XML description of itself and its services. That HTTP port is not fixed. On Windows it is TCP 2869; on embedded devices it is whatever the firmware picked, so read it from the LOCATION value.

Real-world risk, stated honestly

Tenable rates this Info, which is fair for most internal hits. The realistic internal impact is reconnaissance: the SERVER header and description XML hand an attacker the device type, manufacturer, model and firmware, which Tenable notes can help map the network. A UPnP response is also often the first sign of a device nobody inventoried, the problem covered in unknown unknowns: the assets your inventory never listed.

The risk climbs in three situations:

The device is a router or firewall running UPnP IGD. UPnP has no authentication, so any host that can reach the Internet Gateway Device service, including malware on a laptop, can ask it to open inbound port forwards. OpenWrt’s documentation recommends manual port forwarding and leaving UPnP disabled.
SSDP is reachable from the internet. CISA alert TA14-017A lists SSDP as a UDP amplification vector with a bandwidth amplification factor of 30.8 for SEARCH requests. Separately, CERT/CC VU#339275 (CVE-2020-12695, “CallStranger”) describes abuse of the UPnP SUBSCRIBE callback to send traffic to arbitrary destinations, enabling amplified DDoS and data exfiltration. CERT’s workaround is to disable UPnP on internet-accessible interfaces.
The UPnP stack is old. Embedded UPnP libraries have had remotely exploitable bugs. OpenWrt warns that miniupnpd in OpenWrt 10 Backfire is vulnerable to remote code execution.

Bottom line: a printer answering SSDP on a user VLAN is low priority. A gateway answering on its WAN address should be fixed today.

How to confirm it on the host

Start from the scanner’s vantage point and query the flagged address directly:

nmap -sU -p 1900 --script upnp-info 192.0.2.10

If the device answers, the script prints the Server string and a Location URL. Open that URL (for example with curl -s) to see exactly what the device publishes about itself.

Windows: find out what owns UDP 1900 and check the two UPnP services.

Get-NetUDPEndpoint -LocalPort 1900 |
    Select-Object LocalAddress, OwningProcess,
        @{n='Process'; e={(Get-Process -Id $_.OwningProcess).Name}}

# Replace 1556 with the OwningProcess value from above
tasklist /svc /fi "PID eq 1556"

Get-Service SSDPSRV, upnphost | Select-Object Name, Status, StartType

On a Windows 11 machine we checked, UDP 1900 was bound on every interface address by a svchost instance hosting only SSDPSRV (SSDP Discovery), and upnphost (UPnP Device Host) lists SSDPSRV as a dependency. Microsoft documents both with a default startup type of Manual and, on Windows Server 2016, as installed only with Desktop Experience.

Linux:

sudo ss -ulpn | grep ':1900'
sudo ss -tlpn

The first names the process bound to UDP 1900; the second matches the TCP port from the LOCATION URL to a process.

Routers, printers, NAS and cameras: the nmap Server string usually identifies the firmware; then check the admin interface for UPnP, SSDP or DLNA settings.

How to fix it

Routers and firewalls: never expose UPnP IGD

Turn off UPnP (and NAT-PMP or PCP if nothing needs them) in the admin interface and replace automatic mappings with documented manual port forwards. On OpenWrt, UPnP is provided by the miniupnpd package and configured in /etc/config/upnpd:

uci set upnpd.config.enabled=0
uci commit upnpd
/etc/init.d/miniupnpd stop
/etc/init.d/miniupnpd disable

If a segment genuinely needs UPnP IGD, keep it off the WAN and restrict what clients may map. These directives come from the upstream miniupnpd.conf sample (file location varies by distribution):

# WAN interface: never listen here
ext_ifname=eth1
# LAN interface(s) to serve
listening_ip=eth0
# clients may only map ports to their own IP
secure_mode=yes
allow 1024-65535 192.168.0.0/24 1024-65535
deny 0-65535 0.0.0.0/0 0-65535

The upstream sample warns that mixing up the WAN and LAN interfaces introduces security risk, so double check both names.

Printers, NAS and IP cameras

Disable UPnP, SSDP and any DLNA or media server feature you do not use, usually under a network protocols or services page. On NAS boxes and cameras, also turn off remote access options that ask the router for port forwards through UPnP; use a VPN instead. Apply current firmware while you are there. Rescan these devices carefully, as covered in scanning fragile OT, printer and embedded devices.

Windows: disable SSDP Discovery and UPnP Device Host

Microsoft’s Windows Server 2016 service guidance marks both services as OK to disable, and the CIS Windows 10 and 11 benchmarks set both to Disabled at Level 1. Per host:

Stop-Service -Name upnphost, SSDPSRV -Force
Set-Service -Name upnphost -StartupType Disabled
Set-Service -Name SSDPSRV -StartupType Disabled

For a fleet, set both to Disabled in a GPO under:

Computer ConfigurationPoliciesWindows SettingsSecurity SettingsSystem ServicesSSDP Discovery
Computer ConfigurationPoliciesWindows SettingsSecurity SettingsSystem ServicesUPnP Device Host

The underlying value is Start = 4 under HKLMSYSTEMCurrentControlSetServicesSSDPSRV and …Servicesupnphost. Also close the inbound Network Discovery rules for SSDP (UDP 1900) and UPnP (TCP 2869). Record which are enabled first, so you can roll back precisely:

$rules = Get-NetFirewallRule -Name 'NETDIS-SSDPSrv-In-UDP*', 'NETDIS-UPnPHost-In-TCP*'
$rules | Select-Object Name, Profile, Enabled
$rules | Disable-NetFirewallRule

These rule names are the same on every display language. Turning network discovery back on in Settings can re-enable them, so for managed machines add inbound Block rules for UDP 1900 and TCP 2869 in the GPO under Windows Defender Firewall with Advanced Security.

Linux hosts

SSDP on a Linux server usually belongs to an application, such as a DLNA media server or an app embedding a UPnP library. Disable the feature in that application, or stop the service if the host does not need it:

sudo systemctl disable --now <service-name>

If the application must keep running, drop SSDP at the host firewall (adapt to your own ruleset and repeat for IPv6):

sudo iptables -A INPUT -p udp --dport 1900 -j DROP
# or, with ufw
sudo ufw deny 1900/udp

At network boundaries

This is what Tenable’s solution text points at. Deny UDP 1900, plus the TCP ports seen in LOCATION URLs, at the internet edge and between user, guest, server and OT segments. Discovery within a segment keeps working.

How to verify the fix and rescan

Rerun nmap -sU -p 1900 –script upnp-info from the scanner’s segment. You should see no script output and the port reported as closed or open|filtered.
For gateways, run the same command against the public IP from outside your network.
On Windows, Get-Service SSDPSRV, upnphost should show Stopped and Disabled, and Get-NetUDPEndpoint -LocalPort 1900 should find no endpoint.
Rescan with Nessus from the same scanner. Plugin 35711 is a network check, so credentials do not change the result.

What can break and how to roll back

Automatic port forwarding: game consoles, some VoIP and remote-access tools lose inbound connectivity until you add manual forwards.
Windows device discovery: per Microsoft, SSDP-based devices are no longer discovered and hosted UPnP devices stop working. Media streaming to or from DLNA devices, which is built on UPnP, is also affected.
Printer and NAS discovery: clients that found devices through SSDP must add them by IP address or through a print server.
Vendor remote access on cameras and NAS boxes that relied on UPnP mappings.

Rollback commands:

# Windows (Manual is the default startup type)
Set-Service -Name SSDPSRV -StartupType Manual
Set-Service -Name upnphost -StartupType Manual
Start-Service -Name SSDPSRV
# then re-enable only the firewall rules you recorded as enabled, for example
Enable-NetFirewallRule -Name 'NETDIS-SSDPSrv-In-UDP-Active', 'NETDIS-UPnPHost-In-TCP-Active'

# OpenWrt
uci set upnpd.config.enabled=1
uci commit upnpd
/etc/init.d/miniupnpd enable
/etc/init.d/miniupnpd restart

If you used a GPO, set the startup mode back to Manual explicitly. Simply removing the setting does not necessarily restore the previous value.

Common false positive reasons

Scanner on the same segment. SSDP is meant to work locally, so a hit from a scanner inside the VLAN is expected. Decide based on which segments should reach the device.
NAT or port forwarding. UDP 1900 on the reported IP may be forwarded to a different device.
Another listener. A third-party application can bind UDP 1900 itself after SSDPSRV is disabled. Recheck the owning process.
Stale data. The scan predates the change, or a DHCP address now belongs to another device.

FAQ

Is Nessus plugin 35711 a vulnerability?

Not by itself. It is an Info-level detection that a device speaks UPnP. It matters when the device is a gateway, when SSDP is reachable from the internet, or when the UPnP stack is outdated.

Should I block UDP 1900 everywhere?

Block it at the internet edge and between segments. Blocking it inside a segment only breaks local discovery for devices that legitimately use it.

Does disabling SSDP Discovery on Windows break printing?

It stops discovery of SSDP-based devices. Printers already installed by IP address or through a print server keep working.

Is disabling UPnP the same as disabling NAT-PMP?

No. They are separate protocols, although miniupnpd implements both. Plugin 35711 only detects SSDP, so disable NAT-PMP and PCP on the router separately if nothing needs them.

Tracking this finding across many hosts

UPnP findings tend to appear on dozens of hosts after one scan. If you use SITEY, you can upload the .nessus export, have its AI draft host-specific scripts (such as disabling SSDPSRV and upnphost) that run only after human approval through its agents on Windows and Linux endpoints, and re-test each Nessus finding to confirm closure. Routers, printers and cameras still need the admin-side change, and duplicates are merged per scanner, not across scanners.

Discovery and visibility

Scanning and collection

The AI layer

Action and closure

Team and governance

Reporting

UPnP Protocol Detection (Nessus 35711): How to Disable UPnP and SSDP