The Cisco IOS XE Web UI backdoor: what CVE-2023-20198 actually teaches us

In October 2023, Cisco disclosed a vulnerability that let an unauthenticated attacker create a fully privileged local account on any internet-facing IOS XE device with the Web UI feature enabled — no credentials, no prior access, just a request to the right endpoint. Within days, researchers estimated tens of thousands of compromised devices. It's one of the clearest recent examples of a single overlooked feature toggle turning into mass exploitation.

What actually happened

CVE-2023-20198 (CVSS 10.0) affected the Web UI feature in IOS XE — the same HTTP/HTTPS management interface a lot of administrators enable for convenience and then forget about. An unauthenticated attacker could hit the interface and create a local user account with privilege level 15 — full administrative access — with no login required first. Cisco confirmed active exploitation in the wild before the advisory was even fully public.

A few days later, Cisco disclosed a second, related bug — CVE-2023-20273 — showing that attackers were chaining the two together: use the first bug to get the privileged account, then use that access to inject a persistent implant through a separate injection flaw, surviving reboots and giving long-term access back to the device.

CISA added both to the Known Exploited Vulnerabilities catalog within the same week, which is about as clear a "this is being used right now, patch immediately" signal as the ecosystem produces.

What a config audit would have caught — before the CVE ever existed

Here's the part worth sitting with: you didn't need to know about CVE-2023-20198 to have avoided most of the blast radius. "The Web UI / HTTP management interface is enabled and reachable from an untrusted network" is a standard finding in CIS Controls, NIST 800-53 (CM-7, least functionality), and basically every network hardening checklist ever written — completely independent of any specific vulnerability. Disabling management features you don't actively use, and restricting the ones you do to a trusted management VLAN, is baseline hardening advice that predates this CVE by years.

Devices that had already failed (and fixed) that one generic finding — Web UI disabled, or restricted to an internal management network only — were not exposed to this attack, full stop, regardless of patch level. That's the real value of routine config auditing: a meaningful share of "zero-day" impact is actually "known-bad configuration that happened to get a CVE number eventually."

What a config audit would not have caught

To be precise about the limits here: a static config review checks what's configured, not what already happened to a device that was already exposed. If a device was already compromised — the backdoor account already created, the implant already planted — that's a live-device compromise-indicator problem (unexplained local accounts, unusual files, unexpected processes), not something visible in the running-config text itself. Config auditing is a preventive control; it reduces the attack surface a vulnerability like this needs to exist, but it isn't an incident-response or forensics tool, and treating it as one gives false confidence.

The practical checklist

• Disable the HTTP/HTTPS Web UI server feature on IOS XE devices unless it's actively required
• If it must stay on, restrict access to a dedicated management network via ACL — never expose it to the internet or general user VLANs
• Patch to a fixed IOS XE release regardless — this reduces risk from the next bug in the same feature, not just this one
• Audit for unexplained local user accounts on any device that ever had the Web UI exposed during the disclosure window