/SDK/webLanguage Requests in Your Logs: Hikvision CVE-2021-36260 Scans

203.0.113.7 - - [18/Oct/2026:03:51:11 +0000] "PUT /SDK/webLanguage 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 /SDK/webLanguage HTTP/1.1" 404 162 "-" "python-requests/2.31.0"
192.0.2.88 - - [18/Oct/2026:04:02:44 +0000] "PUT /SDK/webLanguage HTTP/1.1" 404 162 "-" "Go-http-client/2.0"

What the request is

/SDK/webLanguage is a path on the embedded web server used by Hikvision network cameras and video recorders. It is not a generic web application path: on a normal Linux web server, a Python app or a PHP site, nothing listens there, and the request can only be a probe for a device.

The reason scanners care about it is CVE-2021-36260, a command injection vulnerability in the web server of some Hikvision products. As the NVD description above states, insufficient input validation lets an attacker launch a command injection attack by sending messages with malicious commands. CISA added it to the Known Exploited Vulnerabilities catalog, which is a reasonable summary of why this path appears in scan traffic years after the advisory: a reachable, unpatched device gives the sender command execution on a network-attached camera that usually sits inside the perimeter.

Both GET and PUT forms of the request turn up in access logs. A bare GET is a cheap existence check — the scanner only wants to know whether something other than a 404 comes back — while the request carrying the injection is the follow-up when a device answers. This page deliberately contains no payload; you do not need one to detect or to block the traffic, and the path alone is enough to match on.

Who sends it

This is undirected, internet-wide scanning. The senders fall into the usual three groups: mass scanners sweeping address ranges for any device that responds, botnets that recruit internet-exposed cameras and recorders into DDoS and proxy infrastructure, and research crawlers that catalogue exposed devices. Nothing about receiving this request implies your organisation was selected.

The user agent is weak evidence. Some clients announce an HTTP library such as python-requests or Go-http-client; many copy a current Chrome string. The shape of the traffic is more telling: no Referer, no requests for CSS, JavaScript or images, several unrelated device and application paths from the same address within a few seconds, and a quick move on once the path returns 404.

Note the capitalisation. The real device path is mixed case (/SDK/webLanguage), so any log search or block rule you write should be case-insensitive rather than matching one spelling.

Is your server exposed?

Check what your own logs already answered, then ask the host itself:

# Every request to this path, with the status code it received
awk 'tolower($7) ~ /\/sdk\/weblanguage/ {print $9, $7}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn

# Anything that was NOT a 404/403 — this is the list that matters
awk 'tolower($7) ~ /\/sdk\/weblanguage/ && $9 !~ /^(404|403)$/ {print}' /var/log/nginx/access.log

# Ask your own server, from your own server
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/SDK/webLanguage

# Any proxy rule that forwards into a camera/NVR network?
grep -rin 'proxy_pass' /etc/nginx/ | grep -vi 'localhost\|127\.0\.0\.1'

Run the curl check against each vhost name you serve, not only the default server, and repeat the awk pass over rotated and compressed logs. The two ways a general-purpose server ends up exposing this endpoint are a reverse-proxy or stream rule that forwards to a device subnet, and a NAT port forward on the same public address that has nothing to do with nginx at all — so check the firewall as well as the web server config.

How to block it

If you run no Hikvision devices, answer the path cheaply and stop logging it:

# Hikvision device endpoint — nothing here serves it
location ~* ^/sdk/weblanguage {
    access_log off;
    log_not_found off;
    return 404;
}

The ~* makes the match case-insensitive, so the mixed-case path and any lower-case variant are both covered, and returning 404 tells the scanner nothing about what exists.

If you do run the devices, an edge rule is not the fix. Patch the firmware per Hikvision’s instructions, as the KEV entry requires, and then remove the device web interfaces from the public internet: put them on a segmented VLAN, reach them through a VPN or jump host, and drop the inbound port forwards. A camera that only answers from inside the network cannot be found by this scan at all. See the NVD entry for CVE-2021-36260 for the affected-product data when you build that inventory.