GET /developmentserver/metadatauploader: SAP NetWeaver Upload Probes

203.0.113.7 - - [18/Oct/2026:03:51:11 +0000] "GET /developmentserver/metadatauploader HTTP/1.1" 404 162 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"
198.51.100.42 - - [18/Oct/2026:04:07:55 +0000] "POST /developmentserver/metadatauploader HTTP/1.1" 404 162 "-" "python-requests/2.31.0"
192.0.2.88 - - [18/Oct/2026:05:19:40 +0000] "GET /developmentserver/metadatauploader HTTP/1.1" 404 162 "-" "Go-http-client/2.0"

What the request is

/developmentserver/metadatauploader is the URL path of the Metadata Uploader belonging to SAP NetWeaver Visual Composer, a component of the NetWeaver Java stack. Where Visual Composer is installed and published, that path is handled by the application server; where it is not, the web server in front answers 404 like it would for any unknown URI.

The scan is a single, exact request — no traversal segments, no query-string fuzzing, no case games in the counted traffic — which makes it one of the cleanest signatures you can grep for. The sender is testing one thing: does this host answer on the Visual Composer uploader path? Any status other than 404 (a 200, a 302 to a logon page, a 403 from the application rather than from your proxy, even a 500) tells the scanner the component is present and reachable, and that is enough to schedule a follow-up attempt.

What makes the follow-up serious is the flaw rendered above: the endpoint’s authorization is missing, so the upload function can be reached without authenticating. An upload endpoint that attacker-controlled clients can reach on a server that also executes code from its own directories is the classic path from one HTTP request to persistent server-side execution, which is why this probe deserves a higher priority than the generic .env and .git/config sweeps in the same log.

Who sends it

Internet-wide. The senders are mass scanners sweeping address ranges for anything that answers on the path, botnets that chain a hit straight into an exploitation attempt, and research crawlers that catalogue exposed SAP systems. Since the flaw’s addition to CISA’s catalogue the path has been a standard entry in off-the-shelf scan lists, so arrival of the request says nothing about whether your organisation was singled out.

The user agent is not evidence. Some clients announce an HTTP library such as python-requests or Go-http-client; many copy a current Chrome string. The shape is more informative: one or two requests from an address, no Referer, no static assets, and the same address moving on to other enterprise-product paths within seconds.

Is your server exposed?

Start from what your own logs already answered, then test the live path from the host:

# Every request to the uploader path, with the status and method it got
awk 'tolower($7) ~ /^\/developmentserver\/metadatauploader/ {print $9, $6, $7}' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn

# Anything that was NOT 404/403 - this is the list that matters
awk 'tolower($7) ~ /^\/developmentserver\/metadatauploader/ && $9 !~ /^(404|403)$/' \
  /var/log/nginx/access.log

# Ask your own server, from your own server, and read only the status code
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1/developmentserver/metadatauploader

# Same check per vhost - a rule added to one server block and forgotten elsewhere
# is the usual way these paths stay reachable
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: erp.example.com' \
  http://127.0.0.1/developmentserver/metadatauploader

Give rotated and compressed logs the same pass with zgrep, and run the checks against every listener that reaches the Java stack, not only ports 80 and 443 — a load balancer or an internal port that publishes the application directly bypasses any rule you add to one nginx vhost.

How to block it

If you run NetWeaver, the fix is SAP’s: apply the vendor’s correction or mitigation for CVE-2025-31324, and remove or disable Visual Composer where the business does not use it. Edge rules are a second layer and buy time, not safety.

# Hosts that do not run NetWeaver: answer the probe and stop logging it
location ~* ^/developmentserver/ {
    access_log off;
    return 404;
}

# Proxies that DO front NetWeaver: let only trusted networks reach the uploader
location ~* ^/developmentserver/metadatauploader {
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
    proxy_pass http://sap_as_java;
}

The case-insensitive regex matches the path however it is cased, and returning 404 rather than 403 tells the scanner nothing about what exists behind the proxy. Alert on any non-404 status for this path, and keep that alert even after patching — it is the cheapest detection you have for a regression that republishes the endpoint.