The Router’s Firewall Took Commands From the Internet. Calix Has Not Shipped a Fix.

The flaw affects the Calix GS7 XGS GS5239XG, also marketed as the GigaSpire 7u10txg, when it runs EXOS 6.6.47. A remote attacker can send one request to the router’s exposed Universal Plug and Play control service and create a persistent port-forwarding rule to an internal device. A camera, network-attached storage appliance or administration interface that appeared protected by NAT can then become reachable from the internet.

The vulnerability is tracked as CVE-2026-75501 and has a CVSS 3.1 score of 9.1. Carnegie Mellon University’s CERT Coordination Center published the finding after it was unable to establish a coordinated response with Calix. No vendor patch or statement was available when this article was prepared.

The request came from the wrong side of the router

Universal Plug and Play, or UPnP, lets devices inside a local network ask the router to open inbound ports. A games console may need a temporary mapping. A peer-to-peer application may need an outside connection to reach a service on the device. The protocol commonly relies on one central assumption: the request originates from the trusted local network.

The affected Calix firmware breaks that assumption. Its MiniUPnPd service binds the WANIPConnection control endpoint to the public WAN interface on TCP port 5000. The service does not authenticate the caller.

Researcher Brian Khan Quintana confirmed four functions were accessible from outside his home network:

• AddPortMapping could create a new inbound route to an internal address.
• DeletePortMapping could remove a legitimate mapping.
• GetGenericPortMappingEntry could enumerate existing rules.
• GetExternalIPAddress could return the gateway’s public address.

His proof of concept created a mapping from a host outside the home. The router accepted the unauthenticated SOAP request with an HTTP 200 response. Setting the lease duration to zero produced a rule with no expiration, and the mapping remained after the gateway was power-cycled.

This is not a case in which an attacker first steals the router administrator’s password or tricks someone into installing an application. Reachability is the only prerequisite described by the research. If TCP port 5000 is exposed and the affected service is running, the control plane accepts the request because it fails to distinguish the public side from the private side.

NAT did not fail. Its administrator was exposed

NAT and a stateful firewall normally block unsolicited connections from the internet. That protection can create a false sense that internal devices do not need the same authentication and hardening as public services.

Here, the packet-filtering function continued to work as configured. The vulnerability gave the attacker a way to change that configuration. The router itself became an unauthenticated administrator for opening paths through the boundary.

The distinction matters for incident response. A scan that confirms the router’s normal management page is closed does not establish that the home network is safe. A malicious mapping can expose a different device, on a different port, and can survive a reboot. Investigators need to inspect the forwarding table as well as the gateway’s firmware and public listeners.

The downstream impact depends on what the attacker chooses to expose. A camera may have a default password, an unpatched web interface or no authentication on a local-only stream. A NAS device may contain sensitive files or a vulnerable administration service. An IoT appliance may become a foothold for scanning other systems. The router vulnerability does not automatically compromise each device, but it removes the network boundary those devices may have been designed to rely on.

The customer may not control the fix

Calix sells this class of gateway through broadband providers. The ISP may provision the device, lock configuration controls and manage firmware distribution. That operating model changes who can remediate the vulnerability.

CERT/CC recommends disabling UPnP until a vendor correction is available. On a gateway where the setting is exposed, the option is under Advanced → Security → UPnP. Disabling it can affect games and applications that rely on automatic port opening, but specific required mappings can be created manually.

Some subscribers may find the setting hidden or locked. CERT/CC advises those users to ask their ISP to disable the service at the carrier level. Providers can also filter inbound traffic to TCP port 5000 before it reaches customer equipment.

This is an important responsibility boundary. A subscriber cannot install a fixed firmware image that does not exist, and may not be able to change the relevant setting. The broadband provider therefore becomes part of the vulnerability-response path even when the vulnerable code belongs to the equipment vendor.

The disclosure process failed where the fix had to begin

Quintana says he sent a detailed report to Calix, the deploying ISP and CERT/CC on 7 June 2026. CERT/CC opened a formal case on 27 June and attempted vendor coordination. The researcher submitted the issue again through Calix’s product-security form on 29 July.

According to both the researcher and CERT/CC, Calix had not provided a substantive response by the coordinated public disclosure on 21 August. The CERT note lists the vendor status as unknown and says no statement was received.

That absence does not prove Calix is ignoring the issue internally, and it does not establish how many deployed gateways are exposed. It does leave customers and broadband providers without a vendor-confirmed affected-version matrix, patch schedule or assurance that later firmware branches are safe.

Defenders should therefore avoid turning one tested configuration into an unsupported global count. The verified scope is the GS5239XG running EXOS 6.6.47. Providers using other releases should test whether the UPnP control endpoint is reachable from the WAN and seek a written answer from Calix.

What providers and users should do now

Broadband providers should treat this as an exposure-management issue across their managed fleet, not wait for individual subscribers to notice an open port.

• Identify the exact model and firmware. Locate GS5239XG or GigaSpire 7u10txg gateways running EXOS 6.6.47, including equipment held as spares or awaiting deployment.
• Test from the public side. Verify whether TCP port 5000 and the UPnP description or control endpoints are reachable from an external network. Do not rely only on the local administration interface.
• Block the service. Disable UPnP where operationally possible or filter inbound TCP/5000 upstream. Confirm the block after the change.
• Inspect existing mappings. Look for persistent or unexplained forwarding rules and determine which internal systems they exposed.
• Investigate downstream devices. If an unknown mapping exists, review authentication, access and network logs on the target device. Removing the rule does not remove an attacker who already reached it.
• Harden local services. Do not treat NAT as the only protection for cameras, storage systems, remote administration or IoT devices. Change default credentials, patch the devices and disable unneeded services.
• Track the vendor response. Obtain a Calix-supported remediation and confirm whether later firmware is affected before declaring the fleet safe.

Residential users who cannot change the UPnP setting should contact their provider and refer to CERT/CC Vulnerability Note VU#756733. They should also review the router’s port-forwarding table and disconnect or isolate sensitive internal devices while exposure remains unresolved.

The security boundary was delegated to an unauthenticated service

The most useful lesson from CVE-2026-75501 is not simply that UPnP can be dangerous. It is that a control designed to operate only on one side of a trust boundary became reachable from the other side, while preserving all of its authority.

The firewall still filtered packets. The attacker could tell it which packets to admit.

Until Calix provides a supported fix, the safest response is to remove that public control path, inspect the rules it may already have created and stop assuming that a private address makes an internal device private.

Sources and further reading

• CERT Coordination Center: Calix GS7 XGS GS5239XG residential router contains missing authentication vulnerability, first published 21 August 2026 and last updated at 14:44 UTC.
• Brian Khan Quintana: The router in my living room was taking orders from strangers, coordinated disclosure published 21 August 2026.
• Calix: GigaSpire Wi-Fi 7 systems.
• BleepingComputer: Unpatched Calix flaw lets hackers bypass NAT to expose internal devices, published 24 August 2026 at 17:14, page timezone not stated.