Calix GS7 routers expose internal home devices via unauthenticated WAN-side UPnP

A high-severity vulnerability in Calix GS7 residential routers lets anyone on the internet rewrite the device's port-forwarding table without a password, dissolving the NAT boundary that normally shields cameras, NAS boxes and other equipment on a home network. The flaw is tracked as CVE-2026-75501 and was published on 21 August 2026 as CERT/CC vulnerability note VU#756733. A dev.to writeup summarizing the advisory, alongside a technical analysis by researcher Brian Khan Quintana and related coverage by BleepingComputer, lays out how it works in practice.

Affected hardware and conditions

The target is the Calix GS7 XGS GS5239XG, also known as the GigaSpire 7u10txg, running EXOS firmware version 6.6.47. The exposed component is the embedded MiniUPnPd 2.3.7 daemon and its UPnP IGD WANIPConnection:1 service. According to the writeup, exploitation requires UPnP to be enabled, the UPnP service to be reachable on TCP port 5000 from the WAN side of the router, and no ISP or upstream firewall blocking that port. Beyond that, an attacker only needs the router's public IP address and correctly formed SOAP requests.

An unauthenticated open door

UPnP is designed for the local network: devices on a LAN ask the router to open ports so consoles, games and cameras work without manual configuration. On the vulnerable router, that same control plane answers requests arriving from the internet.

An attacker first connects to TCP port 5000 on the router's public IP and retrieves the service description from rootDesc.xml, which reveals the WANIPConnection:1 control endpoint at /ctl/IPConn. From there, unauthenticated SOAP calls do the rest. GetExternalIPAddress and GetGenericPortMappingEntry leak the router's public address and its existing forwarding table, and AddPortMapping opens an external port to any internal IP and port the attacker chooses.

The writeup highlights two aggravating details. A rule created with a lease duration of 0 never expires, and in the researcher's tests forwarding rules survived a reboot of the router. DeletePortMapping can also remove legitimate rules, breaking gaming sessions, camera feeds and remote-access setups for the household.

Quiet until it isn't

No user interaction is required, and no prompt, click or notification appears during the attack. According to the writeup, the victim's normal experience may be completely unchanged even while internal services become reachable from the internet. The first visible symptom is often a negative one: services stop working when legitimate mappings are deleted.

For administrators, the indicators are concrete. TCP port 5000 is open on the WAN side, with rootDesc.xml and /ctl/IPConn reachable from outside. The router's forwarding table shows rules with a lease duration of 0, unknown owners or unexpected LAN IP addresses, and those rules persist across reboots. Network monitoring would show HTTP GETs to rootDesc.xml, POSTs to /ctl/IPConn, SOAPAction headers such as AddPortMapping or DeletePortMapping, and inbound connections to newly opened external ports. The writeup cautions that router audit logs alone may not reveal the request source or the time of the change.

No patch at publication time

According to the dev.to summary, there was no patched firmware version and no vendor statement when the advisory was published. The recommended mitigations are to disable UPnP in the management interface, or ask the ISP to do so if the settings are locked; to block inbound TCP port 5000 at the router, a secondary firewall or the ISP; to delete any unauthorized forwarding rules; and to harden internal devices with source restrictions and strong authentication.

The writeup also draws a clear line between exposure and compromise. The initial attack changes router configuration; it does not run code inside the LAN. Actually taking over an internal device requires a second weakness, such as a vulnerability, default credentials or broken authentication on the exposed service. It also states that public reports so far show no recorded incidents and no active attacks against third-party devices.

Why it matters

Millions of small networks rely on NAT as their implicit firewall: devices are safe mostly because nothing outside can reach them. CVE-2026-75501 switches that assumption off with a handful of SOAP requests, and its persistence across reboots defeats the most common home remedy of power-cycling the router. Because these devices are often ISP-managed, affected users may lack the permissions to disable UPnP themselves, which shifts part of the response burden onto providers. Even without observed exploitation, scanning for open port 5000 is trivial, so anyone running GS7 hardware should verify exposure and apply mitigations now rather than wait for a patch. The bug is also a broader reminder that UPnP is a LAN-only protocol, and that NAT alone was never a real security boundary.