Cisco IOS XE Web UI: how to check the external perimeter after CVE-2023-20198 and CVE-2023-20273

Cisco has confirmed exploitation of the CVE-2023-20198 and CVE-2023-20273 chain in the Web UI of devices running Cisco IOS XE. One condition matters here: what is exposed is not “any router with IOS XE”, but a device on which the Web UI feature is enabled over HTTP or HTTPS. Both vulnerabilities are also listed in the CISA Known Exploited Vulnerabilities catalog.

The Cisco advisory describes a sequence that has already been used in practice: CVE-2023-20198 lets an unauthenticated remote user create a local account with privilege level 15, and CVE-2023-20273 lets an authenticated user run commands with elevated privileges. So a check that starts on a Friday evening is better opened not with a list of every IOS XE device, but with two questions: where is the Web UI enabled, and where is it reachable from outside.

What was reachable before the chain started

The Web UI feature is turned on by one of these commands:

ip http server
ip http secure-server

The first applies to HTTP, the second to HTTPS. Cisco suggests looking for them in the configuration with:

show running-config | include ip http server|ip http secure-server

The presence of one of these lines means the corresponding web service is enabled. That is a configuration check, not yet a check of external reachability. The service may be closed off by an ACL, by a firewall, or simply not published through an edge device. The reverse also happens: an internal inventory may show a private address for the router while, from outside, the Web UI is reachable through a separate publishing rule.

The external check therefore has to be run from a host outside your own network. For a first pass over an address range that belongs to the organization, something like this will do:

nmap -Pn -sT -p- --open 203.0.113.0/24

The TCP ports that come back then have to be checked as HTTP/HTTPS services:

nmap -Pn -sV -p 80,443,8443 203.0.113.10

The ports in that command are not a list of IOS XE ports; they are an example for checking an address you have already found. Relying on 80 and 443 alone is not enough: what is actually published is decided by the configuration of the specific perimeter.

At this point the wording of the result matters. A web service answering on a public address does not by itself prove that a vulnerable version of IOS XE is running. And a command run on the device does not prove that the service is reachable from the internet. What justifies an investigation is three signals lining up:

1. an external scanner sees an HTTP or HTTPS service;
2. the address is matched to a Cisco IOS XE device;
3. the Web UI is enabled on that device and an affected version is installed.

That combination is what turns a perimeter finding into a concrete task for the engineer on duty.

How the chain runs

The first step is CVE-2023-20198. According to the CVE record and the Cisco advisory, the vulnerability sits in the Cisco IOS XE Web UI and comes from improper handling of interface elements. When the Web UI is reachable, an unauthenticated remote user can create an account with privilege level 15.

For IOS XE that is not an intermediate web session with limited rights. The local account that gets created receives the highest privilege level covered by the described scenario. After the first step, further requests are already made as an authenticated user.

The second step is CVE-2023-20273. Cisco describes it as a command injection vulnerability in the Web UI component: a local authenticated user can send a crafted request and execute commands with root privileges. In the activity Cisco confirmed, the two flaws were used together — the privileged account created through CVE-2023-20198 provided the authentication that CVE-2023-20273 needs.

In practice the chain looks like this:

reachable Web UI
        ↓
CVE-2023-20198
        ↓
local account with privilege level 15
        ↓
authenticated request to the Web UI
        ↓
CVE-2023-20273
        ↓
command execution with root privileges

This is why a simple version check does not replace a check of what is published. The version answers one question: does the installed release contain the fix. An external scan answers a different one: can a request reach the component where the chain begins at all.

Which versions to check

The IOS XE version can be read with:

show version

The result should be compared against the Fixed Software table in the Cisco advisory for your own release train. Among the fixed releases, Cisco lists:

• IOS XE 16.12.10a;
• IOS XE 17.3.8a;
• IOS XE 17.6.6a;
• IOS XE 17.9.4a.

This list cannot be used as a general rule that “a higher version means a fixed one”. Cisco maintains several release trains, and some releases have no fixed image of their own and a separate migration path instead. What has to be checked is the row for your own train in the vendor's current table, not a comparison of the numeric parts of a version string.

For a device with the Web UI enabled, the order is: record the output of show version first, then find the matching train in the Cisco table, and only after that check external reachability separately. That way a closed management interface and the same component published on a public address do not end up with the same urgency.

What to look for on the device itself

Cisco lists indicators tied to configuration being written through the Web UI. The first quick query:

show logging | include %SYS-5-CONFIG_P

The message that deserves particular attention is the one where the process is shown as:

SEP_webui_wsma_http

The configured local users can be listed like this:

show running-config | include username

An unfamiliar entry, especially one with privilege 15, calls for investigation. Here, too, a name alone is not enough: Cisco recommends looking into users that were not created by an administrator, rather than treating every local account as malicious.

The advisory also gives a check for the presence of the implant through a Web UI URI:

curl -k -X POST "https://DEVICE-IP/webui/logoutconfirm.html?logon_hash=1"

As Cisco describes it, a response containing a hexadecimal value points to the implant being present. The absence of such a response does not remove the need to review users and logs: these indicators answer different questions and do not substitute for one another.

Once an external address has been found, it is worth keeping at least four results in a single incident record:

public IP address and the reachable port
show version
show running-config | include ip http server|ip http secure-server
show logging | include %SYS-5-CONFIG_P

Separately — the local user output and the result of the request to logoutconfirm.html. A set like this makes it unnecessary to argue about whether “the interface looks like Cisco”, and lets you tie an external entry point to the configuration, the version and the signs of change.

Where external perimeter monitoring helps

A one-off inventory only answers for the state at the moment of the check. In this story, the significant change may not be the installation of a new IOS XE version, but the appearance of a new path to a Web UI that was already there: an address being published, a firewall rule being changed, a TCP port being opened.

Continuous perimeter scanning is therefore useful not as a way to make a diagnosis from a banner. It produces two verifiable events: an external web service has appeared, or it has changed. The event then has to be matched with the address owner, the device, the output of show version and the ip http server or ip http secure-server commands.

That is the honest scope of an external perimeter capability. It does not promise to identify a CVE from a single network request. Its job is narrower: to show that management access which was not on a public address yesterday is answering from outside today. For this chain that transition matters, because the first step begins precisely with a remote request to the Web UI.

Where the chain could have been broken

The earliest point is not publishing the Web UI to an untrusted network at all. Cisco recommends disabling the HTTP Server feature where it is not needed:

configure terminal
no ip http server
no ip http secure-server
end

Both variants have to be turned off if both commands are present in the configuration. After the change, an external scan from the same vantage point should stop getting an answer on the service that was previously reachable.

If the Web UI is needed, restricting access to trusted addresses reduces the surface, but does not replace fixing the version. There is no contradiction here: filtering external traffic cuts off the described internet scenario for the remaining sources, while the permitted administrative host stays a separate path to the service.

The next point is installing a fixed release from the Cisco table. It removes the vulnerabilities, but it does not answer the question of what happened before the upgrade. If the device was reachable from outside on an affected version, both pieces of work are needed: the update and the indicator review.

Finally, the chain could have been spotted after the first step — by an unknown user with privilege level 15, or by the SEP_webui_wsma_http event. That is no longer prevention of initial access, but it is a chance not to miss the move to the second vulnerability.

A verifiable outcome for your own environment today looks simple enough:

• the external address no longer accepts a connection to a Web UI you do not need;
• on the device, both server commands are absent, or access is restricted according to the scheme you have agreed on;
• show version matches the fixed release for your own train;
• there are no unknown users and none of the indicators Cisco lists in the logs.

The chain has to be broken at one of these points.