It's not supposed to be exposed on the WAN side. As long as the producers of the device aren't outstandingly incompetent it should be fine.
If the people who write the software are incompetent enough that they have random services listening on the WAN side UPNP is probably the least of the concerns. Unsolicited attacks as you describe require knowledge of the devices on the LAN side anyway. If the gateway is doing its job properly these should not be exposed.
Regardless forwarding any ports at all carries a risk, whether static or dynamic.
That is why I'm fine with UPNP. It's a very useful application that reduces the need for manual configuration for each device behind the NAT.
Obviously if you're the kind of person that has static IPs or IP reservations for every device on your network it's a natural extension of that, but working with this stuff I try and keep my configuration at home to a minimum of complexity, which means UPNP gets to play. So far I've not noted any compromise
Incidentally I do appreciate what you're saying about UPNP.
MiniUPnP < 1.4 Multiple Vulnerabilities
Description
According to its banner, the version of MiniUPnP running on the remote host is prior to 1.4. It is, therefore, affected by the following vulnerabilities :
- An out-of-bounds read error exists in the ProcessSSDPRequest() function in file minissdp.c that allows an unauthenticated, remote attacker to cause a denial of service condition via a specially crafted M-SEARCH request. (CVE-2013-0229)
- A stack-based buffer overflow condition exists in the ExecuteSoapAction() function in the SOAPAction handler, due to improper validation of user-supplied input. An unauthenticated, remote attacker can exploit this, via a long quoted method, to cause a denial of service condition or the execution of arbitrary code.
(CVE-2013-0230)
Solution
Upgrade to MiniUPnP version 1.4 or later.