Skip to content
Sudhir
Vulnerability management

Cisco IOS XE Web UI Vulnerabilities: How to Check Your Exposure

By Sudhir 4 min read

CVE-2023-20198 and CVE-2023-20273 affect the IOS XE Web UI. The first can allow an unauthenticated attacker to create a highly privileged local account. The second can support command injection after access has been gained.

The risk depends on configuration and reachability. An IOS XE device is not exposed merely because it runs IOS XE. The HTTP or HTTPS server must be enabled, and an attacker needs a network path to that management service.

This is a triage guide, not a replacement for Cisco’s advisory. Use the Cisco security advisory for CVE-2023-20198 to determine affected and fixed releases for the exact device and train you operate.

Check whether the web interface is enabled

Run:

show running-config | include ^ip http

Look for either of these commands:

ip http server
ip http secure-server

Their presence means the service is enabled. It does not prove that the service is reachable from the internet.

Check the management path separately. Review interface addresses, routing, NAT, upstream firewall policy, VPN access, and management-plane ACLs. Test reachability from an authorized external location if your change and testing process permits it.

Do not assume that an RFC 1918 address makes the service safe. Port forwarding, remote-access VPNs, jump hosts, or an exposed upstream network can still provide a path.

Record the software release

Run:

show version

Record the full release, device model, installation mode, redundancy state, and image. Compare that information with Cisco’s advisory and software checker.

Avoid copying a fixed-version table from an old blog post. Cisco guidance can vary by release train, and the correct upgrade may change as later maintenance releases become available.

Look for signs of unauthorized access

Start with local users and configuration changes:

show running-config | include ^username
show startup-config | include ^username
show archive log config all
show logging

Compare the output with your source of truth. An unfamiliar privileged account, an unexplained Web UI change, or configuration activity outside an approved window needs investigation.

Review centralized authentication, SIEM, TACACS+, RADIUS, configuration backup, and network telemetry as well. Logs on a compromised device may be incomplete. The absence of an obvious local indicator does not prove that the device is clean.

Cisco Talos published technical context and indicators during the original exploitation campaign. Use the Talos analysis alongside the current Cisco advisory and your incident-response procedure.

Preserve evidence before remediation

If you find an unknown account, suspicious configuration, or other evidence of compromise, do not begin by deleting files and reloading the device.

First:

  1. Restrict the management path to stop further access.
  2. Preserve the running and startup configurations.
  3. Export relevant local and centralized logs.
  4. Record time, software version, uptime, interfaces, users, and recent changes.
  5. Engage your incident-response team and Cisco TAC.

The response team can then decide whether to collect more volatile evidence, rebuild the device, or replace the image. That decision depends on the device, business impact, and available evidence.

Rotate local, TACACS+, RADIUS, API, and automation credentials after containment. If credentials may have been exposed to the device, treat them as compromised even if the accounts still look normal.

Remove unnecessary exposure

If the Web UI is not required, disable it through an approved change:

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

If the Web UI is required, restrict it to a dedicated management network or controlled administrative path. Use device-supported management-plane controls and upstream firewalls. Do not publish ports 80 or 443 for device administration directly to the internet.

Test the change from an authorized management host and from a location that should be denied. A configuration line alone does not prove the path is closed.

Upgrade safely

Use Cisco’s advisory and software checker to select a fixed release. Read the release notes for hardware support, ROMMON requirements, caveats, and upgrade path.

Before upgrading:

  • Back up the configuration and current image information.
  • Confirm available storage and boot variables.
  • Check stack, chassis, or redundancy requirements.
  • Define rollback and console-access plans.
  • Schedule validation for routing, switching, wireless, VPN, and management functions used on the device.

After the upgrade, confirm the running version and management exposure again. Monitor authentication and configuration activity during the following days.

The control that prevents a repeat

Inventory every network-device management interface and test its reachability on a schedule. Record the approved source networks, authentication method, owner, software release, and last review.

The two questions should always have current answers:

  1. Which systems can reach this management service?
  2. Who will know when that answer changes?

Patching closes a known flaw. Restricting and monitoring the management path limits the next one.

Continue reading