GET /geoserver/web/ Requests in Your Logs: Scanning for GeoServer

203.0.113.7 - - [18/Oct/2026:03:51:11 +0000] "GET /geoserver/web/ 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 /geoserver/ HTTP/1.1" 404 162 "-" "python-requests/2.31.0"
192.0.2.88 - - [18/Oct/2026:04:12:03 +0000] "GET /geoserver/web/wicket/bookmarkable/org.geoserver.web.AboutGeoServerPage HTTP/1.1" 404 162 "-" "Go-http-client/2.0"

What the request is

GeoServer is an open source server for sharing and editing geospatial data, usually deployed as a Java web application under the context path /geoserver. Its browser administration interface is an Apache Wicket application served from /geoserver/web/, which is why that single path is the overwhelming favourite in this scan: one GET tells a crawler whether the product is installed, without needing credentials to see the login screen.

The other counted variants do the same job slightly differently. /geoserver/ and /geoserver/index.html are the context root, which a normal install redirects into the web UI. /geoserver/web/wicket/bookmarkable/org.geoserver.web.AboutGeoServerPage is the Wicket bookmarkable URL for the About GeoServer screen, the page that reports the running build — a version fingerprint, if the deployment’s security configuration lets it be rendered without a login.

None of these requests is itself an exploit. They are identification. The reason they matter is the vulnerability detailed above: CVE-2024-36401 lets unauthenticated users reach code execution on a default installation, and it is in CISA’s Known Exploited Vulnerabilities catalog. Mass scanners enumerate hosts that answer on /geoserver/web/ first, then come back against the OGC endpoints. A 404 ends the story; a 200 puts you on a target list.

Who sends it

Internet-wide scanners sweeping whole address ranges, exploitation botnets that chain discovery straight into an attempt against a known-exploited bug, and research crawlers that publish inventories of exposed software. Nothing about receiving these requests means your organisation was chosen.

The user agent is not evidence: some clients declare an HTTP library such as python-requests or Go-http-client, many copy a current Chrome string. The shape of the traffic is more reliable — a handful of paths from one address within a second or two, no Referer, no requests for CSS, JavaScript or images, and a quick move on to the next product’s well-known path once these return 404.

Is your server exposed?

Start with what your logs already recorded, then ask the host itself:

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

# Anything that was NOT 404/403 - this is the list that matters
awk 'tolower($7) ~ /\/geoserver/ && $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/geoserver/web/
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: maps.example.com' http://127.0.0.1/geoserver/

# If GeoServer IS installed: which GeoTools build is deployed?
ls /opt/geoserver/webapps/geoserver/WEB-INF/lib/gt-complex-*.jar 2>/dev/null

Repeat the curl check with the Host header of every vhost you serve, including staging and internal names — a forgotten proxy rule on a secondary vhost is the usual way an instance stays reachable. Give rotated logs the same awk pass, because an exposure may already have been used before it was closed.

If an instance does answer, the only durable answer is the version. Compare it against the patched releases named in the CVE text and upgrade; the documented jar-removal workaround carries the vendor’s own warning that it may break functionality.

How to block it

If you do not run GeoServer, make the 404 cheap and silent in every server block:

# Not our software: answer 404 without touching the backend or the log
location ^~ /geoserver {
    access_log off;
    log_not_found off;
    return 404;
}

If you do run it behind nginx, put the administration interface behind an allowlist so the login page is not internet-facing:

location ^~ /geoserver/web/ {
    allow 10.0.0.0/8;
    allow 192.0.2.0/24;      # VPN egress
    deny all;
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
}

Treat that as hardening of the console only. The OGC request types the CVE names are served from other paths, so restricting /geoserver/web/ reduces who can reach the admin UI but does not remove the vulnerable code — patching to a fixed release does. Blocking the scanning addresses is not worth the effort either: the source pool rotates constantly and the traffic is aimed at ranges, not at you.