How to Find Which of Your Admin Consoles Are Reachable From the Internet

You cannot defend what you did not know was exposed

When a vendor ships an advisory that says "no workaround available" for an internet-reachable console, as Cisco did for the Catalyst SD-WAN Manager bypass CVE-2026-76504, the first question is not "how do I patch" but "is this thing even reachable from the outside, and what else like it is?" Most organizations answer that question badly, because the inventory of what faces the internet drifts away from the architecture diagram the moment someone adds a temporary firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. rule and forgets to remove it. This is a repeatable process for finding every admin console, management UI, and control-plane API that an outsider can touch, so that the next no-workaround advisory does not catch you guessing.

Treat this as a standing capability, not a one-time scramble. The goal is an accurate, current list of externally reachable administrative surfaces, each tied to an owner and a justification, so that when a CVE lands you can answer "are we exposed" in minutes.

Start from the attacker's vantage point

Enumerate your own address space the way an outsider would. Pull the full list of public IP ranges your organization owns or rents, including cloud provider allocations, and the domains and subdomains that resolve to them. Shadow IT and forgotten cloud projects live in the gaps here, so reconcile DNS records, certificate transparency logs, and your cloud accounts against each other rather than trusting any single source.

Then scan those ranges from outside your perimeter, not from inside it, because a scan run from your own network sees rules that an internet client never will. For each live host, record which ports answer and what service sits behind each one. Administrative interfaces cluster on a handful of ports: HTTPS management UIs, SSH, and device-specific management ports. Cisco's SD-WAN hardening guidance, for instance, calls out that the ports used for administration should not be exposed directly to the internet at all. Flag anything that presents a login page, an API that accepts credentials, or a device management banner.

Confirm what each exposed service actually is

A port that answers is a lead, not a conclusion. Fingerprint each exposed service enough to know the product and, where you can, the version, because that is what lets you map an exposure to a specific advisory later. A management console that identifies itself, a TLS certificate naming an appliance, or an API that returns a recognizable error shape all help. Resist the urge to probe aggressively against production control planes; you are building an inventory, not running an engagement, and heavy probing of a device like an SD-WAN Manager can disrupt the fabric it controls.

Record, for every confirmed administrative surface: the product, the version if known, the owning team, why it is exposed, and what compensating controls sit in front of it. That last column matters because the same understanding of blast radiusBlast Radius🛡️The full set of systems, data, and access an attacker can reach after compromising a given asset. Ranking assets by blast radius rather than by how exposed they are pushes high-reach systems like a firewall management console to the top of the priority list. that makes a central controller dangerous, explored in the news coverage of CVE-2026-76504, tells you which exposures to close first. A console that administers thousands of downstream devices outranks a single appliance's login page.

Close the gap with a choke point

Most administrative surfaces have no business being reachable from the open internet. The remediation pattern is consistent across products. Put the console behind a filtering device and allow only known, trusted source addresses. Move administration onto a dedicated management subnet that users never route to directly. Require operators to come through a jump host or a VPN, so the console's own login page is never the first thing an attacker meets. Where a management UI must be reachable by a small set of partners, an allowlist of their addresses is far stronger than relying on the application's authentication alone, precisely because authentication is what bypass bugs defeat.

The reason this works is that it removes the attacker's precondition. An unauthenticated bypass like the encoding mismatch behind CVE-2026-76504 still needs a network path to the vulnerable endpoint. If the only hosts that can send a request to the Manager are a short list you control, a flaw that would otherwise be internet-exploitable becomes reachable only from inside a trusted segment. The mechanism of that particular bypass is worth understanding in its own right, which we cover in How an Encoding Mismatch Between Two Parsers Defeats an Access Rule.

Keep the inventory alive

An exposure inventory decays. Schedule the external scan on a recurring basis and diff each run against the last, so that a newly opened port or a freshly published subdomain surfaces as an alert rather than as a surprise during the next incident. Tie the inventory into your vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. management so that when a product you run appears in a KEV entry, you already know whether an instance of it is externally reachable and who owns it.

When the advisory does arrive and offers no mitigation, this inventory is what turns a frantic all-hands into a scoped task. You will know exactly which instances face the internet, which can be walled off immediately behind a choke point, and which have to be patched first. That triage, especially when the vendor gives you no configuration to fall back on, is the subject of Why 'No Workaround Available' Should Change How You Triage a Patch.