Vulnerability Note VU#184540
Incorrect implementation of NAT-PMP in multiple devices
Original Release date: 23 Oct 2014 | Last revised: 28 Oct 2014
Many NAT-PMP devices are incorrectly configured, allowing them to field requests received on external network interfaces or map forwarding routes to addresses other than that of the requesting host, making them potentially vulnerable to information disclosure and malicious port mapping requests.
CWE-200: Information Exposure
NAT-PMP is a port-mapping protocol in which a network address translation (NAT) device, typically a router, is petitioned by a trusted local network host to forward traffic between the external network and the petitioning host. As specified in RFC 6886, "The NAT gateway MUST NOT accept mapping requests destined to the NAT gateway’s external IP address or received on its external network interface." Additionally, mapping requests "must" be mapped to the source address of the internal requesting host. When a NAT-PMP device fails to enforce these restrictions and is unsafely configured, it may accept malicious port mapping requests or disclose information about itself. Rapid7’s report describes the scope of the problem and the vulnerabilities that may emerge from incorrect configurations and implementations NAT-PMP:
During our research, we identified approximately 1.2 million devices on the public Internet that responded to our external NAT-PMP probes. Their responses represent two types of vulnerabilities; malicious port mapping manipulation and information disclosure about the NAT-PMP device. These can be broken down into 5 specific issues, outlined below:
Interception of Internal NAT Traffic: ~30,000 (2.5% of responding devices)
Interception of External Traffic: ~1.03m (86% of responding devices)
Access to Internal NAT Client Services: ~1.06m (88% of responding devices)
DoS Against Host Services: ~1.06m (88% of responding devices)
Information Disclosure about the NAT-PMP device: ~1.2m (100% of responding devices)
Rapid7 also indicates that incorrect configurations of miniupnpd are the likely culprit for most vulnerable instances. Miniupnpd is a light-weight UPnP daemon that also supports NAT-PMP and is widely available on all major platforms. It is possible for the internal and external network interfaces in miniupnpd to be interchangeably configured by implementers, which may explain how some devices are vulnerable.
Additional details may be found in the advisory from Rapid7.
A remote, unauthenticated attacker may be able to gather information about a NAT device, manipulate its port mapping, intercept its private and public traffic, access its private client services, and block its host services.
Configure NAT-PMP Securely
Developers and administrators implementing NAT-PMP should exercise care to ensure that devices are configured securely, specifically that
the LAN and WAN interfaces are correctly assigned,
NAT-PMP requests are only accepted on internal interfaces, and
port mappings are only opened for the requesting internal IP address.
Although the NAT-PMP vulnerabilities are not due to flaws in miniupnpd’s code, an update has been released that more strictly enforces RFC 6886. As of version 1.8.20141022, miniupnpd discards NAT-PMP packets received on the WAN interface. The default configuration file, miniupnpd.conf, now contains additional comments to encourage more secure configurations.
Deploy firewall rules to block untrusted hosts from being able to access port 5351/udp.
Consider disabling NAT-PMP on the device if it is not absolutely necessary.
Vendor Information (Learn More)
VendorStatusDate NotifiedDate UpdatedGrandstreamAffected23 Sep 201428 Oct 2014
Netgear, Inc.Affected08 Oct 201428 Oct 2014
RadinetAffected23 Sep 201428 Oct 2014
SpeedifiAffected23 Sep 201428 Oct 2014
TechnicolorAffected16 Oct 201428 Oct 2014
TendaAffected23 Sep 201428 Oct 2014
Ubiquiti NetworksAffected08 Oct 201428 Oct 2014
ZTE CorporationAffected23 Oct 201428 Oct 2014
ZyXELAffected08 Oct 201428 Oct 2014
Apple Inc.Not Affected10 Oct 201421 Oct 2014
MikroTikNot Affected23 Sep 201427 Oct 2014If you are a vendor and your product is affected, let
CVSS Metrics (Learn More)
Thanks to Tod Beardsley and Jon Hart of Rapid7, Inc, for reporting this vulnerability. Thanks to Thomas Bernard of the MiniUPnP project for his assistance in the coordination and remediation effort.
This document was written by Joel Land.
21 Oct 2014
Date First Published:
23 Oct 2014
Date Last Updated:
28 Oct 2014
FeedbackIf you have feedback, comments, or additional information about this vulnerability, please send us email.