GET /webui/ Requests in Your Logs: Cisco IOS XE Web UI Scanning

203.0.113.7 - - [18/Oct/2026:03:51:11 +0000] "GET /webui/ HTTP/1.1" 404 162 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
198.51.100.42 - - [18/Oct/2026:03:51:12 +0000] "GET /webui HTTP/1.1" 404 162 "-" "python-requests/2.31.0"
192.0.2.88 - - [18/Oct/2026:04:12:03 +0000] "GET /webui/index.html HTTP/1.1" 404 162 "-" "Go-http-client/2.0"

What the request is

/webui/ is the base path of the Cisco IOS XE Software web UI, the HTTP management interface on Cisco routers and switches running that operating system. A GET /webui/ is a fingerprint request: the scanner is not exploiting anything yet, it is asking whether something on this address answers with the IOS XE management front end. If it does, the host goes on a target list.

The list exists because of the pair of flaws recorded in this page’s CVE section. The first, CVE-2023-20198, lets a remote unauthenticated attacker create a local account with privilege level 15 on an exposed device; the second, CVE-2023-20273, lets an authenticated attacker inject commands to the underlying operating system as root. Chained, they turn a reachable web UI into full control of a network device and, in the exploitation Cisco documented, an implant written to the file system. Both are in CISA’s Known Exploited Vulnerabilities catalog. That is why a path this short keeps getting hit years later: the payoff is an edge router, not a web page.

The variants are all the same probe. The bare /webui without a trailing slash and /webui/index.html catch servers that redirect or that do not serve a directory index, and that is about as much variety as this scan needs — one cheap GET per host, with the response code and body doing the identification.

Nothing guarantees the responder is IOS XE. Other appliances and applications also mount an interface under /webui, so the path is a hypothesis the scanner then confirms from the response. On a general-purpose web server it is pure background noise.

Who sends it

Internet-wide scanning: mass scanners sweeping address ranges for device management planes, botnets that feed confirmed hits into an exploitation queue, and research crawlers that catalogue exposed infrastructure. Nothing in a /webui/ request means your organisation was chosen.

The user agent proves little — some clients announce an HTTP library, many copy a current Chrome string. The shape is the giveaway: one or two paths from an address within a second or two, no Referer, no follow-up requests for CSS, JavaScript or images, and the same address appearing in your log against other device and framework paths in the same minute.

Is your server exposed?

Two separate questions. On the web server, read what your log already answered:

# Every /webui request in the log, with the status it received
awk 'tolower($7) ~ /^\/webui(\/|$|\?)/ {print $9, $7}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

# Anything that was NOT 404/403 — the only lines that need a human
awk 'tolower($7) ~ /^\/webui(\/|$|\?)/ && $9 !~ /^(404|403)$/' /var/log/nginx/access.log

# Ask your own server, from your own server, and read the status code
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/webui/
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: staging.example.com' http://127.0.0.1/webui/

Repeat the curl check with the Host header of each vhost, and give rotated logs the same pass.

The question that actually matters is on the network side: does any IOS XE device of yours answer HTTP or HTTPS from the internet or from an untrusted network? Check your edge ACLs, NAT rules and firewall policies against your device inventory, and have the network team confirm the web UI’s state on each box from the device configuration — not by probing it from outside.

How to block it

On the web server, answer the probe and stop paying for it:

# Cisco IOS XE web UI probes: nothing here, do not log
location ^~ /webui {
    access_log off;
    log_not_found off;
    return 404;
}

The ^~ prefix match covers /webui, /webui/ and everything beneath it, and returning 404 tells the scanner nothing.

That rule only silences the noise. The real control is on the devices: remove any exposure of the IOS XE web UI to the internet or to untrusted networks, apply Cisco’s fixed releases for both CVEs, and follow Cisco’s own guidance for checking whether a device was already compromised — unexplained local accounts at privilege level 15 and unaccounted configuration changes are the things to hunt for. Federal agencies also have the BOD 23-02 compliance requirement CISA names in its entries for these CVEs.