How to Fix CVE-2023-20198: Cisco IOS XE Web UI Privilege Escalation (Nessus 183167)

CVE-2023-20198 is a critical (CVSS 10.0) flaw in the Cisco IOS XE web UI that lets an unauthenticated attacker create a privilege 15 account. Attackers chained it with CVE-2023-20273 to get root and plant an implant. Fix it by upgrading to a fixed release (such as 17.9.4a) and disabling or restricting the HTTP server until then.

Because this pair was mass-exploited before a patch existed, the fix has a third step that most scan findings do not: check whether the device was already compromised before you trust it again.

What the scanner is actually detecting

In Nessus the finding is titled Cisco IOS XE Software Web UI Privilege Escalation (cisco-sa-iosxe-webui-privesc-j22SaA4z), plugin ID 183167, in the CISCO family, rated Critical. It maps to the Cisco advisory of the same ID and covers two CVEs, both tracked as Cisco bug ID CSCwh87343:

• CVE-2023-20198 (CVSS 10.0): a web UI flaw that lets a remote, unauthenticated attacker create a local account with privilege level 15 access.
• CVE-2023-20273 (CVSS 7.2): a second web UI flaw that the attacker used with that new account to elevate to root and write an implant to the file system.

Tenable states that the plugin has not tested for the flaw itself and relies on the device’s self-reported version number. It depends on the Host/Cisco/IOS-XE/Version knowledge base item, so it fires when Nessus has identified the IOS XE release, usually through a credentialed scan. In short, the finding means “this device runs a release Cisco lists as affected.”

Exposure is a separate question. Per Cisco, the flaws are exploitable only when the HTTP Server feature (the web UI) is enabled with ip http server or ip http secure-server. Cisco lists ASA, FTD, ISE, classic IOS, NX-OS and IOS XE releases earlier than 16 as not affected.

Real-world risk

This is not a theoretical finding. Cisco published the advisory on October 16, 2023 while the flaw was already being exploited, and Cisco Talos traced the first suspicious activity to September 18, 2023. Attackers created local accounts (Talos saw names such as cisco_tac_admin, cisco_support and cisco_sys_manager), then used CVE-2023-20273 to install a Lua-based implant that Talos later named BadCandy. Both CVEs are in the CISA Known Exploited Vulnerabilities catalog (see our explainer on how the CISA KEV catalog works), and Tenable lists public exploits in Metasploit and Core Impact.

Privilege 15 is full administrative control: the holder can read every secret in the configuration and change routing or access lists. Two facts shape the response:

• Reboots remove the implant, not the accounts. Talos reports that the implant is not persistent, but the local accounts the attacker created survive a reload.
• Reachability decides urgency. A web UI that was reachable from the internet while unpatched should be treated as possibly compromised. One limited to a locked-down management network is lower risk, but still open to anyone already inside it. Knowing which device management interfaces face the internet is a core part of external attack surface management scope.

If the HTTP server is off, the flaw cannot be reached, but the vulnerable code stays on the device until you upgrade.

How to confirm it on the device

From the device CLI, check the running release. The output includes a line such as Cisco IOS XE Software, Version 17.09.04a:

show version | include Version

Check whether the web UI is enabled, using the command from Cisco’s advisory:

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

If the output contains ip http server or ip http secure-server, the feature is on. Cisco notes one exception: if ip http active-session-modules none is also present, the flaws are not exploitable over HTTP, and if ip http secure-active-session-modules none is present, they are not exploitable over HTTPS. For a readable summary, including any access class applied, run:

show ip http server status

Next, look for signs of compromise. List local accounts and compare them with the accounts you expect:

show running-config | include username

Search the log for the messages Cisco lists as indicators, and search your syslog server too, because the local buffer rolls over:

show logging | include SEP_webui_wsma_http|WEBLOGIN_SUCCESS|INSTALL_OPERATION

The full messages look like this. Treat any unknown username or unexpected filename as suspicious:

%SYS-5-CONFIG_P: Configured programmatically by process SEP_webui_wsma_http from console as user on line
%SEC_LOGIN-5-WEBLOGIN_SUCCESS: Login Success [user: user] [Source: source_IP_address] at time
%WEBUI-6-INSTALL_OPERATION_INFO: User: username, Install Operation: ADD filename

Cisco’s advisory also gives an implant check you run from a workstation, replacing systemip with the device address. A hexadecimal string in the response indicates the implant is present:

curl -k -H "Authorization: 0ff4fbf0ecffa77ce8d3852a29263e263838e9bb" -X POST "https://systemip/webui/logoutconfirm.html?logon_hash=1"

Attackers later changed the implant to evade that check. Talos published a generic request for the later variants, curl -k “https://DEVICEIP/%25”, and documents the responses that indicate an infected or clean device in its post. A clean result proves little alone, because a reload clears the implant.

How to fix it

Step 1: contain now by disabling or restricting the web UI

Cisco’s decision tree is simple. If the device does not run services that need HTTP or HTTPS (the advisory gives eWLC as an example), disable the HTTP Server feature. If both commands are configured, you need both:

configure terminal
 no ip http server
 no ip http secure-server
 end
copy running-config startup-config

If you need the web UI, restrict it to trusted networks. This follows Cisco’s example; replace the subnet with your management network:

configure terminal
 access-list 75 permit 192.168.0.0 0.0.0.255
 access-list 75 deny any
 ip http access-class ipv4 75
 end
copy running-config startup-config

Older releases use ip http access-class 75 without the ipv4 keyword. Always save: Cisco points out that unsaved changes are reverted on reload, and the upgrade in Step 2 reloads the device. Cisco is explicit that there are no workarounds that address the vulnerabilities, so both options are mitigations, not fixes.

Step 2: upgrade to a fixed release

Note the “a” suffix: 17.9.4 without it is still affected unless the SMU is installed. For any other train or platform, enter your exact release in the Cisco Software Checker, which shows the earliest fixed release, and use it to confirm that the release you plan to install is fixed.

On Catalyst 9000 switches running in install mode, Cisco’s upgrade guide uses the install workflow. Back up the config, then run the steps separately so you can validate before committing:

copy running-config bootflash:pre-upgrade.cfg
show install summary
install add file bootflash:<fixed-image>.bin
install activate
! the device reloads; after validating it, run:
install commit

Routers and devices in bundle mode follow the upgrade procedure in their own release notes. If you take the SMU route, follow the installation notes that ship with the SMU.

Step 3: clean up if you find signs of compromise

• Remove unknown accounts after confirming with the device owners that none is a legitimate break-glass account: no username cisco_tac_admin in global configuration mode, and so on.
• Rotate every secret the attacker could have read: local passwords, the enable secret, SNMP communities, TACACS+ and RADIUS keys, and VPN keys.
• Diff the running config against your last known-good backup to find other changes, then handle the device through your incident response process.

How to verify the fix and rescan

1. show version reports a fixed release, and on install-mode devices show install summary shows it as committed.
2. show ip http server status shows the server disabled, or the expected access class applied.
3. show running-config | include username lists only accounts you recognize.
4. From a network that should not reach the web UI, curl -k -m 5 https://DEVICEIP/ should time out or be refused.
5. Rescan with the same credentials. Plugin 183167 should stop reporting once the version is fixed. If you only applied the workaround, the finding stays open by design; record it as mitigated with an expiry date, the same way you would document compensating controls for a KEV entry you cannot patch yet.

What can break and how to roll back

• Disabling the HTTP server removes the web UI and breaks anything that talks to the device over HTTP or HTTPS, with eWLC as Cisco’s example. Check for controllers and automation first. To roll back, re-enter ip http server or ip http secure-server.
• The access class can lock out administrators if the subnet is wrong. SSH and console access are not affected, so fix it with no ip http access-class ipv4 75 and a corrected ACL.
• The upgrade reloads the device, so schedule an outage. On Catalyst 9000, install activate starts an auto-abort timer (120 minutes by default); if you do not commit before it expires, the switch rolls back. After a commit, show install rollback lists rollback points and install rollback to id <n> restores one. Hold off on install remove inactive until the new release has proven stable.

Common false positive reasons

• Web UI disabled. A version-based check may still flag a device with no HTTP server configured. The flaw is not reachable, but the code is present, so record it as mitigated rather than false.
• SMU installed. A version-only check may not account for an SMU. Keep the show install summary output as evidence and document the exception.
• Stale scan data. Results collected before the reload still show the old release. Rescan after the upgrade is committed.

FAQ

Does disabling the HTTP server fix CVE-2023-20198?

No. It removes the attack vector, but Cisco says there are no workarounds that address the vulnerabilities. You still need a fixed release.

Will rebooting the device remove an attacker?

Partly. A reload removes the implant, but accounts the attacker created survive it. Check and remove them explicitly.

Does the same upgrade fix CVE-2023-20273?

Yes. Both CVEs share bug ID CSCwh87343 and the fixed releases in the same advisory.

Are ASA or NX-OS devices affected?

No. Cisco lists ASA, FTD, ISE, IOS, NX-OS and IOS XE releases earlier than 16 as not affected.

Tracking this finding across many devices

Across many switches and routers, the hard part is tracking which devices are affected, mitigated or upgraded. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export and supports per-finding retest for Nessus findings, so you can confirm plugin 183167 closes after each upgrade. Its AI triage can suggest false positives with evidence, and a human makes the final call.

Sources

• Cisco Security Advisory: Multiple Vulnerabilities in Cisco IOS XE Software Web UI Feature
• Tenable Nessus plugin 183167
• Cisco Talos: Active exploitation of Cisco IOS XE Software Web Management User Interface vulnerabilities
• Cisco IOS HTTP Services Command Reference
• Cisco: Upgrade Guide for Catalyst 9000 Switches