PatchDayAlert
Analysis · 6 min read · 1,143 words By Colten Anderson

The Cisco IOS XE reboot that wasn't remediation

Patching CVE-2023-20198 and rebooting the box clears the web shell but leaves the rogue admin account behind. If you ran one IOS XE web UI on the public internet in late 2023, you have an account audit to do before you close the ticket.

The Cisco IOS XE reboot that wasn't remediation

If you reboot a compromised IOS XE box and call it fixed, you’re wrong, and the device is still owned. The BadCandy implant doesn’t survive a reload. The privilege-15 account the attacker created on the way in does. That’s the whole operational story of CVE-2023-20198, and it’s still catching people out: the Australian Signals Directorate was warning of active BadCandy exploitation as recently as November 2025, more than two years after the patch shipped.

What changed

In October 2023 Cisco disclosed two chained IOS XE web UI flaws that had already been exploited as zero-days since at least September 18. CVE-2023-20198 is a CVSS 10.0 authentication bypass; CVE-2023-20273 is a CVSS 7.2 command injection. Chained, they let anyone who could reach the web UI go from one unauthenticated HTTP request to a full admin account, then to root and a Lua web shell. No credentials, no user interaction.

The first flaw landed in CISA’s KEV catalog on October 16 with a remediation deadline of October 20, two days before patches existed. The expected interim move was to disable the web UI. Patches shipped October 22.

What it means for your environment

The scope is wide. Any device on IOS XE release 16 or later with ip http server or ip http secure-server configured is in play: Catalyst switches and routers, ASR aggregation routers, NCS systems, wireless controllers, access points, branch routers, physical and virtual. If you run Rockwell Allen-Bradley Stratix 5800 or 5200 industrial switches, those are OEM IOS XE builds and in scope on their own fix track. What’s not in scope: ASA, Firepower Threat Defense, ISE, classic IOS, and NX-OS. None share the web UI stack.

The exposure was not theoretical. Shodan indexed roughly 145,000 IOS XE hosts with reachable web UIs at disclosure. Censys counted about 41,983 already-compromised devices on October 18. If your edge or campus switches were managed through the web UI from anywhere routable, assume you were in the blast radius until you’ve proven otherwise.

The attacker’s first move was to create a local privilege-15 account, commonly named cisco_tac_admin, cisco_support, or cisco_sys_manager. The BadCandy web shell that came after it is non-persistent and clears on reboot. The account doesn’t. Patch and reload all you want; the credential the attacker minted is still sitting in your running config with full administrative rights.

This matters because the obvious remediation, “patch the box and reboot it,” produces a device that looks clean to most scans and is still wide open. The implant made that worse on purpose. Around October 23 the visible infection count dropped sharply with no matching wave of patching. Fox-IT found the reason: the actor had updated BadCandy to require a specific Authorization header before responding, so naive scanners got silence and logged compromised devices as healthy. When Fox-IT adjusted their probe to send the header, they counted roughly 37,890 devices still actively compromised. If your asset inventory leaned on an external scan in that window, it lied to you.

What you need to do

If you have not patched, do both moves at once.

  • Kill the web UI now, before you schedule the upgrade. Run no ip http server and no ip http secure-server in global config (both, if both are enabled), then copy running-configuration startup-configuration. If you genuinely need the web UI, ACL it down to a trusted management subnet. This is also a standing CISA BOD 23-02 expectation: management interfaces don’t belong on the public internet.
  • Patch to the fixed train. The fixed versions are 17.9.4a, 17.6.6a, 17.3.8a, and 16.12.10a (16.12.10a is Catalyst 3650/3850 only). SMU hot-patches exist for the 17.9.4 and 17.6.5 base releases if a full train upgrade can’t move fast enough.
  • Check for the implant before you assume you’re clean. Cisco Talos published a curl probe against the BadCandy endpoint; a hex string in the response means the shell is live. Snort coverage is in rules 3:50118, 3:62527-62529, and 3:62541-62542.
  • Audit the running config for accounts you didn’t create. This is the step people skip, and it’s the one that matters most. Per the ASD post-compromise checklist: find and remove unexpected privilege-15 users, check for unknown tunnel interfaces, and review TACACS+ AAA command accounting for configuration changes you can’t account for. Patch before you reconnect the device to the internet, not after.

The ASD also documented something worth flagging to your change board: the actor appeared able to tell when the implant was removed and reinfect devices as they came back online. Neither Cisco nor CISA formally mandated reimaging in 2023, but for a device you’ve confirmed as compromised, account cleanup plus patching may not be enough if the attacker established other persistence. That’s a judgment call your IR process owns, not a checkbox.

The window

If you’re patched and the web UI was never internet-facing, this is closed. Confirm that with a config check and move on; not every old critical is a fire.

If you patched but never audited accounts, that’s the open item, and it’s been open since 2023. Pull the running config, grep for unexpected privilege-15 users, and close it this week.

If you have unpatched IOS XE with a reachable web UI in 2026, that’s not a maintenance-window conversation. The interim mitigation is two CLI commands and takes effect immediately. Run them today, then schedule the upgrade.

One thing the public record doesn’t give you: attribution. A February 2025 SOCRadar analysis links continued IOS XE exploitation to Salt Typhoon, but that draws on 2024-2025 campaign activity, not a forensic tie to the 2023 mass compromise, which Cisco Talos never attributed. It doesn’t change what you do. The remediation is the same whoever was on the other end of that HTTP request, and it’s the account audit, not the reboot, that closes it.

Sources

Share

Related field notes

Get the free CVE triage cheat sheet

Subscribe and we'll email you the one-page triage flow for fresh CVEs. Plus the weekly digest.

Subscribe