The gateway my internet provider installed in my home was answering commands from anyone on the internet, with no password, no login, and no record that it had happened. A stranger could have opened a door straight through my firewall to any device in my house. This is what I found, how I confirmed it, and what happened when I tried to tell the company that built it.
My ISP-issued Calix residential gateway exposes its UPnP control service on the public internet. That service is supposed to be reachable only from inside your own home network. On this device it also listens on the outside, on TCP port 5000, and it does whatever it is asked without ever checking who is asking.
One unauthenticated request from anywhere in the world is enough to open a permanent hole through the router's firewall to any device inside the house. No password. No prompt. Nothing on screen. The rule survives a reboot.
I teach human physiology, so forgive me the comparison, but this is essentially a problem of a barrier that forgot which side it was facing.
Your router's job is to be a wall between your home and the internet. Unsolicited traffic from outside does not get in. That is the entire point of it.
UPnP is the polite exception to that rule. When your game console or your printer needs an incoming connection, it asks the router from the inside, and the router opens a specific port for it. The important word is inside. The request is trusted precisely because it can only come from a device already sitting on your network. That is why the protocol never bothered to add authentication: the location of the request was the authentication.
So when that same control service is also listening on the outside of the wall, the one assumption holding the whole design together is gone. It is not that a lock failed. It is that the door was built without one, because everyone agreed it would only ever be reached from inside the house.
I was looking at my own connection, doing the kind of inventory anyone can do on hardware they own: what does this thing actually expose to the world?
Scanning my own public address from outside my network, TCP port 5000 answered. That was the first surprise, since nothing about a residential gateway should be advertising a service there. Requesting rootDesc.xml from that port returned the device's UPnP description document, which politely listed its services and told me exactly where to send commands.
The second surprise was that the control endpoint worked. I sent a properly formed SOAP request asking the router to create a port mapping, with no credentials of any kind, from a machine that was nowhere near my house. The router returned HTTP 200 and created the rule.
I want to be honest about the feeling there, because I think it matters. I expected a rejection. What I got back was a cheerful confirmation that my firewall had just been reconfigured by a stranger, and that stranger happened to be me.
| Model | Calix GS7 XGS GS5239XG residential gateway |
|---|---|
| Firmware | Calix EXOS 6.6.47 |
| UPnP daemon | MiniUPnPd 2.3.7 |
| Exposed service | UPnP IGD WANIPConnection:1 |
| Exposed on | WAN interface, TCP port 5000 |
| Weakness | CWE-306, Missing Authentication for Critical Function |
Two endpoints were reachable from the internet. The first, http://[WAN_IP]:5000/rootDesc.xml, is the device description. The second, http://[WAN_IP]:5000/ctl/IPConn, is the control channel that accepts commands.
Four actions were confirmed working without any authentication, from outside the network:
AddPortMapping, which creates a new inbound hole through the firewallDeletePortMapping, which removes an existing oneGetGenericPortMappingEntry, which lists what is already mappedGetExternalIPAddress, which reports the gateway's public addressEverything below was run against my own hardware, on my own connection. I re-enabled UPnP only for the length of the test and turned it off again immediately afterward. The request was sent from a host outside my network, and it mapped external TCP port 9999 to an internal address.
POST /ctl/IPConn HTTP/1.1
Host: [WAN_IP]:5000
Content-Type: text/xml; charset="utf-8"
SOAPAction: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping"
<?xml version="1.0"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewRemoteHost></NewRemoteHost>
<NewExternalPort>9999</NewExternalPort>
<NewProtocol>TCP</NewProtocol>
<NewInternalPort>9999</NewInternalPort>
<NewInternalClient>192.168.1.1</NewInternalClient>
<NewEnabled>1</NewEnabled>
<NewPortMappingDescription>poc</NewPortMappingDescription>
<NewLeaseDuration>0</NewLeaseDuration>
</u:AddPortMapping>
</s:Body>
</s:Envelope>A lease duration of 0 asks for a mapping with no expiration, and the rule was still in place after I power cycled the device. Whatever an attacker opens, stays open.
Think about what actually sits behind a home router now. Security cameras. Baby monitors. A network drive with tax returns and family photos on it. A work laptop. The management page of the router itself. All of it is protected by one assumption, which is that the outside world cannot reach in and start rearranging things.
With this flaw, someone who knows the public IP address can:
None of that requires a password, a phishing email, a malicious download, or a single click from the person who lives there. It is one HTTP request. That is why it scores where it does:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N = 9.1, Critical
Turn UPnP off. On this gateway it is under Admin Panel → Advanced → Security → UPnP, set to Disabled. This closes the exposure until the vendor ships a fix.
You will lose automatic port opening, which some games and consoles use. If you need a specific port open, add it by hand in the router's port-forwarding page. That is a small inconvenience compared to leaving the control channel open to the internet, and honestly, it is worth checking your forwarding table anyway to see whether anything is there that you did not put there yourself.
The real fix belongs to the vendor and is not complicated: the UPnP control service should never be bound to or accept requests on the WAN interface. It is a LAN-only function. It always was.
This is the part I did not expect to be the hard part.
On June 7, 2026 I sent a full technical writeup to the vendor's published security address, to the ISP deploying the hardware, and to CERT/CC, all on the same day. I gave them everything: model, firmware, endpoints, reproduction steps, severity assessment.
The vendor never substantively responded. Not an acknowledgment, not a ticket number, not a request for more detail.
CERT/CC opened a formal case and spent weeks trying to reach them through their own preferred channel, a product security web form on their website. I submitted through that form as well, on July 29. It returned a "thank you" on screen and nothing else. No reference number, no confirmation email, no way to even check whether a human had seen it.
So the advisory is publishing without them.
The technical finding is straightforward. A service was bound to the wrong interface. Someone will fix it in an afternoon once they decide to.
The part worth sitting with is that the process worked exactly as designed on every side except one. I found something on my own equipment, I did not publish it, I reported it privately and completely, and a neutral coordinator spent two months trying to hand a critical finding to the company that could actually fix it. Every step of that was done in good faith. The only thing missing was someone on the other end willing to pick up.
I am new to coordinated disclosure. What I have learned is that the disclosure is not the technical work. The technical work is the easy part. The disclosure is patience, documentation, and being willing to keep knocking on a door that may never open, because the people living behind these routers deserve the fix even if nobody ever writes back to say thank you.
If you are holding a finding and wondering whether it is worth the trouble of reporting it properly: it is. Report it anyway. Someone at CERT/CC will take you seriously even when the vendor does not.