Port 1900 – SSDP (Simple Service Discovery Protocol)

Port 1900 is the default port for SSDP (Simple Service Discovery Protocol), the discovery layer of UPnP (Universal Plug and Play). It runs over UDP: devices announce themselves and search for one another by sending HTTP-style messages to the multicast group 239.255.255.250:1900, and every SSDP reply carries a LOCATION header pointing at the device’s UPnP description XML — the entry point to its control (SOAP) endpoints. SSDP ships enabled across consumer and enterprise gear: home routers, smart TVs, printers, IP cameras, DLNA media servers, and a huge population of IoT devices. That ubiquity is the problem — an SSDP responder reachable from the internet is both a DDoS amplifier and a live map of a device’s UPnP attack surface, which is why an exposed port 1900 is worth chasing on any external scan.

Why It’s Open

SSDP is on because UPnP is on, and UPnP is on because “it just works” is a feature vendors ship by default. When a media player looks for a DLNA server, a game console asks the router to open a port, or a phone finds a printer, that discovery happens over SSDP on UDP 1900. The listener lives on routers and CPE (customer-premises equipment), Windows hosts (the SSDP Discovery service), smart TVs, cameras, NAS boxes, and cheap IoT hardware that nobody re-configures after unboxing.

None of that needs to face the internet — SSDP is a local-network protocol scoped to a multicast group. But millions of routers answer SSDP on their WAN interface anyway, either through a firmware bug or a misconfiguration, and that is exactly the population attackers scan for. Where 1900 answers, the device’s UPnP control plane is usually one request away, and the same box often exposes the UPnP SOAP endpoints seen on port 5000.

Common Risks

• Amplification / reflection DDoS — the headline. SSDP is one of the internet’s worst UDP reflectors. A spoofed M-SEARCH query (source address forged to the victim) makes the responder send a much larger reply to the victim. US-CERT (TA14-017A) measured an SSDP bandwidth amplification factor of about 30×, and with millions of internet-exposed CPE answering on 1900, attackers have a near-limitless pool of reflectors. This is the same class of abuse as NTP on port 123 and SNMP on port 161.
• UPnP / IGD abuse and NAT injection. The LOCATION header advertises the device’s UPnP description, from which an attacker reaches the IGD (Internet Gateway Device) SOAP actions. On a router that exposes them, AddPortMapping and WANIPConnection let an attacker punch holes through NAT and forward internal services straight to the internet — the UPnProxy technique, weaponised at scale in the EternalSilence campaign to expose internal SMB.
• Information disclosure. SSDP replies and the linked description XML leak the device model, firmware version, UUID, and internal URLs — a clean fingerprint that lets an attacker match an IoT device to known exploits before touching it.
• Exploitable UPnP stacks. The daemons behind SSDP/UPnP have carried pre-auth remote code execution bugs — the libupnp (Portable SDK) SSDP-parser overflow (CVE-2012-5958) and the MiniUPnPd SOAP overflow (CVE-2013-0230) — so an exposed responder can be a code-execution target, not just a leak.
• Attack surface for IoT botnets. Poorly maintained SSDP/UPnP devices are prime recruits for botnets (Mirai-class) that lean on the same weak, abandoned IoT firmware also reached over Telnet on port 23.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Check if the port is open

nmap -sU -p 1900 -sV <target>

Pull device and UPnP details (LOCATION, model, description URL)

nmap -sU -p 1900 --script=upnp-info <target>

Discover UPnP devices on the local segment (multicast)

nmap --script=broadcast-upnp-info

Send a raw M-SEARCH discovery probe

echo -en 'M-SEARCH * HTTP/1.1\r\nHOST:239.255.255.250:1900\r\nMAN:"ssdp:discover"\r\nMX:1\r\nST:ssdp:all\r\n\r\n' | nc -u -w2 <target> 1900

Metasploit — information discovery and amplification check

msfconsole -q
use auxiliary/scanner/upnp/ssdp_msearch
set RHOSTS <target>
run

# Flag responders usable as reflection/amplification sources
use auxiliary/scanner/upnp/ssdp_amp
set RHOSTS <target>
run

Interact with the UPnP/IGD control plane

# Interactive UPnP client (ships on Kali): discover, then send actions
miranda

# umap probes UPnP commands reachable from the WAN even when unadvertised
umap.py -c -t <target>

If the IGD profile answers, enumerate WANIPConnection and test whether AddPortMapping is callable — a router that lets you create a port-forward from the outside is an immediate, high-severity finding. Every open reflector, exposed IGD action, and leaked device fingerprint is worth recording as you go, so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

• CVE-2020-12695 — “CallStranger.” The UPnP specification (before the 2020-04-17 fix) lets a device accept a SUBSCRIBE request whose Callback delivery URL points at a different network segment than the event-subscription URL. That turns internet-facing UPnP devices into tools for SSRF-style internal port scanning, DLP-bypassing data exfiltration, and amplified reflected TCP DDoS. It affects a vast vendor list (Windows 10, Xbox One, and routers/printers from Asus, Broadcom, Canon, Cisco, HP, Huawei, Netgear, TP-Link, and more). CVSS 7.5; the researcher’s checker PoC is on GitHub.
• CVE-2012-5958 — Stack-based buffer overflow in the unique_service_name function of the SSDP parser in libupnp (the Portable SDK for UPnP, formerly the Intel SDK) before 1.6.18. A single crafted UDP SSDP packet gives unauthenticated remote code execution. CVSS v2 10.0 — the centrepiece of Rapid7’s 2013 “Security Flaws in Universal Plug and Play,” affecting thousands of devices that embed libupnp; weaponised on Exploit-DB and in Metasploit (exploit/multi/upnp/libupnp_ssdp_overflow).
• CVE-2013-0230 — Stack-based buffer overflow in the ExecuteSoapAction / SOAPAction handler of the UPnP HTTP service in MiniUPnPd 1.0, reachable via a long quoted method — remote code execution. CVSS v2 10.0. This is the UPnP control side that SSDP advertises.
• CVE-2013-0229 — The ProcessSSDPRequest function in MiniUPnPd before 1.4 mishandles a crafted SSDP request, triggering a buffer over-read that crashes the service (denial of service). CVSS v2 7.8.
• CVE-2019-12106 — Use-after-free in the updateDevice function of MiniSSDPd 1.4 and 1.5 lets a remote attacker crash the daemon — a remote denial of service. CVSS 7.5.

SSDP amplification itself isn’t a single CVE — it’s a design/technique issue in how open UDP responders answer spoofed queries, catalogued by US-CERT in TA14-017A (UDP-Based Amplification Attacks) alongside DNS, NTP, and SNMP.

Mitigation

• Never expose 1900/UPnP to the internet. SSDP is a LAN protocol — block inbound UDP 1900 at the CPE/edge so nothing outside the local segment can reach the responder. An internet-facing port 1900 has no legitimate purpose.
• Disable UPnP where it isn’t needed. Turn UPnP off on routers and IoT devices that don’t require automatic port-forwarding or discovery. This closes the IGD AddPortMapping abuse (UPnProxy) and the CallStranger surface in one move.
• Kill SSDP reflection. Disable SSDP responses on WAN interfaces and rate-limit multicast, so a misconfigured box can’t be used as a reflector.
• Block spoofed sources at the edge (BCP 38). Reflection only works because source addresses are forged; anti-spoofing neutralises the amplification abuse that also affects NTP (123), SNMP (161), and DNS (53).
• Patch device firmware. Update to close the libupnp/MiniUPnPd RCE and DoS bugs above; on abandoned hardware where no patch exists, disable UPnP entirely.
• Segment IoT. Isolate SSDP/UPnP devices on their own VLAN, and log traffic to and from port 1900 so scanning and abuse stand out.

Real-World Example

In November 2018, Akamai documented EternalSilence, a variant of the wider UPnProxy abuse. Attackers scanned the internet for routers answering UPnP, and where the IGD profile allowed it, called AddPortMapping to inject NAT rules — tagged galleta silenciosa (“silent cookie”) — that forwarded the router’s internal-facing TCP 139 and 445 out to the internet. That re-exposed the SMB services behind hundreds of thousands of home routers to the EternalBlue (CVE-2017-0144) and EternalRed (CVE-2017-7494) exploits. Out of roughly 3.5 million potentially vulnerable routers, Akamai found 277,000 still open to UPnProxy and 45,000 already carrying the malicious mappings. The lesson is the one pentests flag on day one: the devices weren’t breached through a UPnP zero-day — they simply answered UPnP control requests from the WAN that they should never have accepted.

FAQ

What is port 1900 used for?

Port 1900/UDP is where SSDP (Simple Service Discovery Protocol) listens. It’s the discovery layer of UPnP: devices multicast M-SEARCH queries and NOTIFY announcements to 239.255.255.250:1900 to find each other and advertise services like media servers, printers, and router port-forwarding. Every reply points at a UPnP description that leads to the device’s control endpoints.

Is port 1900 TCP or UDP?

SSDP uses UDP on port 1900. The connectionless UDP exchange — one small query, one reply — is exactly what makes SSDP usable as an amplification reflector. The UPnP control actions the discovery step points to are then carried over HTTP/SOAP (typically TCP), but discovery itself is UDP 1900.

Is port 1900 dangerous?

On the local network it’s routine. Exposed to the internet it’s a real problem: the responder can be abused as a ~30× DDoS amplifier, its replies leak device model and firmware for targeting, and if the router’s UPnP IGD is reachable an attacker can port-forward internal services out (UPnProxy) or exploit stack bugs like CVE-2012-5958 for code execution. Treat an internet-facing port 1900 as an active exposure.

What is an SSDP amplification attack?

An attacker sends a small M-SEARCH request to an open SSDP responder but spoofs the source address to the victim’s. The responder’s much larger reply goes to the victim instead of the attacker. With a bandwidth amplification factor around 30× (US-CERT TA14-017A) and millions of exposed devices, this turns SSDP into one of the internet’s most effective reflection DDoS vectors.

How do I secure or close port 1900?

Disable UPnP on any router or device that doesn’t need it, and firewall inbound UDP 1900 at the edge so the SSDP responder is never reachable from the internet. Disable SSDP responses on WAN interfaces, patch device firmware for the libupnp/MiniUPnPd bugs, and add BCP 38 anti-spoofing to kill the reflection vector. Rescan with nmap -sU -p 1900 <target> to confirm it no longer answers.

TL;DR

• Service: SSDP (Simple Service Discovery Protocol) — the discovery layer of UPnP, over UDP
• Default port: 1900/UDP (multicast group 239.255.255.250); UPnP control/SOAP often on port 5000
• Biggest risk: ~30× reflection/amplification DDoS plus UPnP IGD abuse (AddPortMapping/UPnProxy) and CallStranger (CVE-2020-12695)
• Mitigation: never expose 1900/UPnP to the internet, disable UPnP where unused, patch firmware, and add BCP 38 anti-spoofing — the same defense that matters for NTP (123) and SNMP (161)