Data Exfiltration & Reflected Amplified TCP DDOS & Port Scan via UPnP SUBSCRIBE Callback

About vulnerability

The CallStranger vulnerability that is found in billions of UPNP devices can be used to exfiltrate data (even if you have proper DLP/border security means) or scan your network or even cause your network to participate in a DDoS attack.

The vulnerability – CallStranger – is caused by Callback header value in UPnP SUBSCRIBE function can be controlled by an attacker and enables an SSRF-like vulnerability which affects millions of Internet facing and billions of LAN devices. This vulnerability can used for

  • Bypassing DLP and network security devices to exfiltrate data
  • Using millions of Internet-facing UPnP device as source of amplified reflected TCP DDoS (not same with )
  • Scanning internal ports from Internet facing UPnP devices

Because this is a protocol vulnerability, it may take a long time for vendors to provide patches. Visit this site, CVE-2020-12695 , for detailed information, affected devices, software, and to follow updates. OCF updated UPnP specification on 17.04.2020 to remediate this vulnerability.
Check new specification on OCF Web site .

Get Detailed Technical Report and PoC Code on GitHub


Because UPnP is managed by Open Connectivity Foundation (OCF), We first contacted them. Summarized Timeline:

  • 20.12.2019: First contact with OCF and report delivery
  • 26.12.2019: Report delivery confirmed by OCF
  • 09.01.2020: Report rejected by OCF commenting “this is not a protocol issue; this is vendor implementation error”
  • 09.01.2020: Detailed information and possible impacts of vulnerability was given to OCF
  • 14.01.2020: OCF declared “IGD (Internet Gateway Devices) UPnP endpoint assumed to be on LAN
  • 14.01.2020: Replied to OCF: None of devices on report is IGD
  • 15.01.2020: OCF replied “vendors on the report has been contacted”
  • 15.01.2020: Replied to OCF: Protocol specification must be cleared and all vendors should be contacted.
  • January to April: Sent notification to vendors and CERTs
  • 09.04.2020: Sent notification to OCF about public disclosure timeline as 21.04.2020.
  • 14.04.2020: VU#339275 assigned by CERT Coordination Center, Carnegie Mellon University
  • 16.04.2020: Because some vendors requested extra time, public disclosure was postponed to 05.05.2020
  • 17.04.2020: OCF updated UPnP protocol specification.
  • 01.05.2020: Because some ISPs requested extra time, public disclosure postponed to June 08, .2020
  • 07.05.2020: CVE-2020-12695 assigned by MITRE
  • 08.06.2020: Release date

Am I Vulnerable & What to do?

Billions of UPNP devices on the local network and millions of UPnP devices on the Internet are exposed . CallStranger is a protocol vulnerability thus almost all UPnP devices (and probably yours) must be updated, . You can check if your devices are vulnerable or not with our tool on GitHub

Home Users

Home users are not expected to be targeted directly. If their internet facing devices have UPnP endpoints, their devices may be used for DDoS source. Ask your ISP if your router has Internet facing UPnP with CallStranger vulnerability -there are millions of consumer devices exposed to Internet- . Don't port forward to UPnP endpoints. Home users don't need to disable UPnP for this vulnerability. They just need to be sure UPnP endpoint is not exposed to Internet.


ISP's need to check their DSL/Cable routers’ UPnP stack , ask vendors to update if devices have vulnerable SUBSCRIBE functions. ISP's can block access to well known UPnP Control & Eventing ports if accessible from Internet (there are millions). Also ISP's can reconfigure CPE's with help of TR-069 .

Device Vendors

You need to patch your devices' UPnP stack depending on new UPnP Specification on OCF Web site. Some UPnP stacks like miniupnp (after 2011) are not vulnerable


It may take long time for vendors to patch UPnP devices, enterprises should take their own actions. Depending on defense-in-dept approach, enterprises may choose different mitigations.

A. Internet facing devices

  • 1. Close UPnP Ports to the Internet if there is no business/technical need.
  • 2. Close UPnP Services’ port (different from UDP 1900) to the Internet . To find out these ports check products documentation or use our test tool, a port scanner like Nmap or UPnP Device Spy.

C. Intranet

  • 1. Disable UPnP service of IP camera, printer, routers and other devices if it is not a business or technical requirement.
  • 2. Check these devices’ Internet access policy (B1)

Frequently Asked Questions

  • How many devices are affected?

    Because Windows, XBox One and most TV and Routers are affected, we can easily say that billions of device affected.

    • This just an SSRF. Why so important?

      As we stated in detailed technical report this is not a simple SSRF. With combining attacker controlled URI and multiple Callback headers, it creates new attack techniques.

    • Why did we give a name to this vulnerability?

      This is not a single-product / brand vulnerability. Nearly all devices and software with UPnP implementation from different product families (operating systems printers, TV’s, routers– UPnP Forum had 400+ members in 2015 are susceptible to this vulnerability. Tracking with CVEs may not be suitable for this kind of vulnerability. Vulnerable devices may have their own CVE’s.

    • Theorical or applicable?

      We see data exfiltration as the biggest risk of CallStranger. Checking logs is critical if any threat actor used this in the past. This is nearly the same impact as :

      IP Forwarding Enabled - Medium - Nessus Plugin ID 50686 Synopsis The remote host has IP forwarding enabled.
      The remote host has IP forwarding enabled. An attacker can exploit this to route packets through the host and potentially bypass some firewalls / routers / NAC filtering.
      Unless the remote host is a router, it is recommended that you disable IP forwarding.

      Because it also can be used for DDoS, we expect botnets will start implementing this new technique by consuming end user devices. Because of the latest UPnP vulnerabilities,enterprises blocked Internet exposed UPnP devices so we don't expect to see port scanning from Internet to Intranet but Intranet2Intranet may be an issue.

    • Is this a code execution vulnerability?

      This vulnerability is NOT about code execution. We found some buffer overflow problems on some devices but they are out of scope of this research.

    • Other researches

      We credited all security researches about UPnP Eventing in past on our detailed technical report. We think this research touches areas never researched before. Thomas Bernard blocked notify traffic to other hosts in 2011 for miniupnp and millions of devices are not vulnerable because of his "security-by-default" approach.

      Update on 09 June 2020:


      I googled the Internet for similar research whether my research says something new or just restates a former vulnerability . There are some hints about DoS/DDoS. There is no information about amplification or Internet facing UPnP services. I couldn’t find anything about data exfiltration and port scanning techniques. Most of the research was focused on UPnP devices itself.


      Thomas Bernard saw possible risk of Callback to different hots earlier and fixed miniupnp.

      revision 1.61

      date: 2011/06/27 11:05:59; author: nanard; state: Exp; lines: +121 -23

      IPv6 support for UPnP events.

      Security checks in UPnP events.

      and Changelog.txt :


       IPv6 support for UPnP events.

       Security checks in UPnP events.


      The eventing part of UPnP allows you to register a callback URL, which is called as soon as a state variable changes. The latest values of the state variables are sent using POST to the callback URL. I have not checked if this callback URL is restricted to be on the device that subscribed, or that it can be any URL. If it is the latter (which I think) then eventing can be used for attacking a site every time someone does something that makes the state of a state variable change, such as making or deleting a portmapping.


      Just like any program, the UPnP server does have variables or event states stored. The UPnP protocol does provide functionality for eventing. Here the clients subscribe to change in the states of the control points and notify them accordingly. This can be abused by creating a subscription under the spoofed address. This is possible as the UPnP does not define any validation for subscription and start notifying on the host address for any change in the state. With enough subscriptions, the chaos can be created. Event subscription

      SUBSCRIBE publisher_path HTTP/1.1

      HOST: publisher_host:publisher_port

      CALLBACK: <delivery_URL>

      NT: upnp:event

      TIMEOUT: Second-requested subscription duration


      4.4 Denial of Service

      Although the initial plan was to attack the service its subscribers list by leaving and rejoining the network, a simpler way was found. The same Callback URL is allowed to be used for an unlimited amount of times and thereby it has become suitable for the same attack: Fill the subscribers list of the service in such a way that it cannot accept any new subscriptions. By setting the timeout to ’infinite’ a subscribed message will never expire until UPnP is disabled. This attack is done by creating a while-loop in which a new subscription request is sent over and over again. The Callback URL is set to the same IP address and contains a unique part, which is simply the iteration number of the while-loop. This means when the loop is at 421 the Callback URL will look something like: In this way output can be easily monitored on the control point. This approach was tested on both IGD devices and both were prone to this attack, which was to be expected since both stacks use libupnp. On the Sitecom device it took on average around 14000 subscriptions to create a denial of service. The Edimax device needed around 18000subscriptions on average before it stopped working. Before the mass subscription request the output of Nmap looked like this:

      joeri@localhost# nmap -v -PN -p 52869

      Interesting ports on STATE SERVICE

      52869/tcp open unknown

      After the mass subscription request the output of Nmap looked like this:

      joeri@localhost# nmap -v -PN -p 52869

      Interesting ports on STATE SERVICE

      52869/tcp closed unknown

      It clearly shows that UPnP is no longer working



      The Denial of Service vulnerability is due to the absence of any proper constraint on the process which is responsible for downloading the device description of a UPnP capable device. Generally, the NOTIFY message sent by a new UPnP device contains information about the location from where the control point (CP) can obtain its device description. This description lists the services the device offers and instructions for using them. By design, this description could reside on a third-party server rather than on the actual UPnP device itself. In the Denial of Service attacks, an attacker can send a malformed NOTIFY message to an UPnP-capable computer, directing the specific port and server from which the UPnP device description can be downloaded. If the size of the directed device descriptor is huge, it can consume memory and processor time on vulnerable systems, resulting in performance degradation and eventual system crash. It is also possible to perform Distributed Denial of Service (DDoS) attack since UPnP protocol doesn’t check for excessive network announcements. An attacker could specify a third-party server as the host for the device description in the NOTIFY directive. If enough machines responded to the directive, it could have the effect of flooding the third-party server with bogus requests, in a distributed denial of service attack. As with the first scenario, an attacker could either send the directives to the victim directly, or to a broadcast or multicast domain

    • Other protocols with Callback

      We searched all RFC's for callback data and put the list to GitHub. Researchers can find CallStranger-like vulnerabilities in these protocols.

    • Thanks

      Special thanks to & Vijay Sarvepalli , MITRE, OCF for coordinating disclosure of this vulnerability. After 6 months and thousands of emails, hundreds of National CERT'/ CERT's / PSIRTS involved in this disclosure. Also special thanks to Umit Sen for encouraging this personal research

Vulnerable Devices

The list will be updated

Confirmed Vulnerable Devices

  • Windows 10 (Probably all Windows versions including servers) - upnphost.dll 10.0.18362.719
  • Xbox One- OS Version 10.0.19041.2494
  • ADB TNR-5720SX Box (TNR-5720SX/v16.4-rc-371-gf5e2289 UPnP/1.0 BH-upnpdev/2.0)
  • Asus ASUS Media Streamer
  • Asus RT-N66U Firmware:
  • Asus Rt-N11
  • Belkin WeMo
  • Bose SoundTouch 10 (http://x.x.x.x:8091/QPlay/Event)
  • Broadcom ADSL Modems
  • Canon Canon SELPHY CP1200 Printer
  • Cisco X1000 (Linksys X1000) - (LINUX/2.4 UPnP/1.0 BRCM400/1.0)
  • Cisco X3500 (Linksys X3500) - (LINUX/2.4 UPnP/1.0 BRCM400/1.0)
  • D-Link DVG-N5412SP WPS Router (OS 1.0 UPnP/1.0 Realtek/V1.3)
  • Denon X3500H (LINUX UPnP/1.0 Denon-Heos/155415)
  • EPSON EP, EW, XP Series (EPSON_Linux UPnP/1.0 Epson UPnP SDK/1.0)
  • FRITZ!Box (FRITZ!Box 4020 UPnP/1.0 AVM FRITZ!Box 4020 147.06.83)
  • HP Deskjet, Photosmart, Officejet ENVY Series (POSIX, UPnP/1.0, Intel MicroStack/1.0.1347)
  • Huawei HG255s Router - Firmware HG255sC163B03 (ATP UPnP Core)
  • Huawei MyBox (Linux/3.4.67_s40 UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00)
  • JRiver DLNA Server 19.0.163 (Windows, UPnP/1.1 DLNADOC/1.50, JRiver/19)
  • LG webOS TV OLED55C9PLA (Linux/i686 UPnP/1,0 DLNADOC/1.50 LGE WebOS TV/Version 0.9)
  • Linksys router (http://x.x.x.x:49152/upnp/event/Layer3Forwarding)
  • NEC AccessTechnica WR8165N Router ( OS 1.0 UPnP/1.0 Realtek/V1.3)
  • Philips 2k14MTK TV - Firmware TPL161E_012.003.039.001
  • Samsung UE55MU7000 TV - Firmware T-KTMDEUC-1280.5, BT - S
  • Samsung MU8000 TV
  • Synology NAS (Linux/3.10.105, UPnP/1.0, Portable SDK for UPnP devices/1.6.21)
  • TP-Link TL-WA801ND (Linux/2.6.36, UPnP/1.0, Portable SDK for UPnP devices/1.6.19)
  • TP-Link Archer VR200 (Linux/, UPnP/1.0, Portable SDK for UPnP devices/1.6.19)
  • Trendnet TV-IP551W (OS 1.0 UPnP/1.0 Realtek/V1.3)
  • ZTE MF275R (ZTE/1.0 UPnP/1.0 MiniUPnPd/1.4)
  • Zyxel VMG8324-B10A (LINUX/2.6 UPnP/1.0 BRCM400-UPnP/1.0)

Devices Waiting External Confirmation

This list is provided by script users. After we confirm vulnerable or not, we will move to Vulnerable or Not Vulnerable section

  • Dell B1165NFW
  • Nokia HomeMusic Media Device
  • Plutinosoft Dynamic UPnP stack
  • Siemens CNE1000 Camera
  • Sony Media Go Media application
  • Toshiba TCC-C1 Media Device

Not Vulnerable Devices

  • miniupnpd >1.6 (2011)
  • Ubiquiti UniFi Controller
  • Ruckus Zone Director Access Point
  • Stream What You Hear Stream What You Hear 1.5
  • Netgear WNHDE111 Access Point
  • Panasonic BB-HCM735 Camera
  • Panasonic VL-MWN350 wireless doorphone


Yunus Çadırcı is Cyber Security Senior Manager at EY Turkey. He has 15+ years of experience in different areas of cyber security including application security, telecommunication security, IoT/OT security, firmware analysis and red teaming. In his spare time, he makes security research and plays Dota 2.