Hikvision web server command injection, and the older auth bypass in the same estate

An unauthenticated command injection in the Hikvision camera web server, alongside a 2017 improper-authentication flaw in an overlapping product line; both are recorded by CISA as exploited.

NVD lists 256 products for CVE-2021-36260. Nineteen of them carry a firmware version range, and every one of those nineteen is a network video recorder. The other 237 name a model and stop. So for the cameras — which is what most of you are actually running — there is no version data in the record to match against, and a CPE-driven scan cannot answer the question you have.

The second CVE on this page, CVE-2017-7921, is nine years old, sits in a partly overlapping camera line, and only entered CISA's KEV catalogue in March 2026. Its ICS-CERT advisory still says there are no known public exploits. Those two statements are both current, and they disagree.

What it is#

CVE-2021-36260 is CWE-78, OS command injection, in the web server on the camera firmware. NVD's description is two sentences:

A command injection vulnerability in the web server of some Hikvision product. Due to the insufficient input validation, attacker can exploit the vulnerability to launch a command injection attack by sending some messages with malicious commands.

No endpoint, no parameter, no affected build. "Insufficient input validation" is the entire mechanism as NVD states it. Any more specific account of how the input reaches a shell is somebody's reconstruction — including anything you read in a bulletin like this one. The record references two Packet Storm write-ups, one of them titled against build 210702; we have not reviewed either, and they are the place to look for what the request actually contains.

What the record does give you is AV:N/AC:L/PR:N/UI:N. Network-reachable, low complexity, no privileges, no user interaction.

CVE-2017-7921 is CWE-287, improper authentication, in an older line. Same CVSS vector, different failure, and a different outcome: per NVD it yields privilege escalation and access to sensitive information, not code execution. One discrepancy to be aware of if you triage by score — ICS-CERT scored this flaw 10.0 in ICSA-17-124-01 (retrieved 5 September 2026); NVD carries 9.8.

What an attacker needs#

Network reachability to the camera's web port. No credential, no user to phish, no local access.

This is why the usual reassurance fails. "It sits behind the login page, and only the ops team has the password" describes a control that CVE-2017-7921 defeats outright and that CVE-2021-36260 does not have to touch — the flaw is in the web server, and the vector records PR:N. Both need the same thing, which is a route to port 80, 443 or whatever the integrator moved it to.

Impact and blast radius#

CVE-2021-36260 gives command execution on an embedded Linux device that runs continuously and, in most estates, ships its logs nowhere. From there, an attacker reaches whatever the camera's network segment reaches: the recorder it streams to, the VMS server that manages it, any switch or router management interface on the same subnet.

Stolen video is the visible outcome. The one that costs more is a durable foothold on a host that carries no endpoint agent, appears in no patch cycle, and is filed in the asset register as equipment rather than as a computer.

Inference, not fact. Three judgements sit above and in the mitigations below, none of them in NVD, KEV or EPSS. First: that the web server runs as root. That is conventional on this device class and would make the outcome a root shell rather than a constrained one — the record does not say, and CVSS S:U tells you nothing about it, so check it on firmware you hold. Second: that camera VLANs are commonly less isolated than their design documents claim. Third: that a "segregated" camera network often still has a VMS or recorder host with an interface in both networks. We have no data on how often either of the last two is true. Read them as things to test on your own routing table, not as findings.

Exploitation evidence#

Fact, from KEV. CVE-2021-36260 was added on 10 January 2022, 110 days after NVD published it, with a remediation deadline of 24 January 2022 — four years and seven months past. CVE-2017-7921 was added 5 March 2026, due 26 March 2026, also past. Both entries record ransomware use as Unknown, which means not established rather than ruled out.

The required actions are quoted verbatim in KEV. For CVE-2021-36260: Apply updates per vendor instructions. For CVE-2017-7921: Apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. The second is CISA's current standard action template and should not be read as a statement about this product's support status.

Reported, second-hand. The Record, 23 August 2022, retrieved 5 September 2026, covering an analysis by CYFIRMA: "more than 80,000 Hikvision cameras are still vulnerable to the critical command injection flaw". The same article reports that in December, Fortinet researchers observed "payloads attempting to leverage this vulnerability", one of which "tries to drop a downloader that exhibits infection behavior and that also executes Moobot, which is a DDoS botnet based on Mirai". We have not opened the CYFIRMA PDF; the 80,000 is as The Record reported it. It is a scan-derived exposure count from August 2022, four years old, and it counts reachable devices rather than compromised ones. Do not carry it forward as a current figure.

The ICS-CERT advisory for CVE-2017-7921, ICSA-17-124-01 — the URL the record carries, which now redirects to CISA — was last revised 4 May 2017 and still reads: "No known public exploits specifically target these vulnerabilities." Retrieved 5 September 2026. CISA's own KEV catalogue has said otherwise since March 2026 and the advisory has not been revised to match. Triage that reads the vendor page and the ICS advisory and stops will get this one wrong.

Both EPSS figures were calculated on 4 September 2026: CVE-2021-36260 at 0.99869, 99.962nd percentile, and CVE-2017-7921 at 0.99998, 99.99th. EPSS is a modelled probability of exploitation in the next thirty days — not a severity score, and not an observation of your network. Both sit at the instrument's ceiling. The ordering between 0.99869 and 0.99998 is noise; there is no "which first" to extract from it.

Affected products, and what the record omits#

CVE-2021-36260 resolves to 256 distinct products, CVE-2017-7921 to 58. Grouped by model-number prefix, the 2021 list is not only cameras:

The type field is null on all 256 entries in the record. The right-hand column is our reading of Hikvision's model-number scheme, not something NVD asserts. The counts are exact.

The 19 rows you can act on#

These are the only entries under either CVE that a version check can settle. All are recorders.

The other 237 carry no version range whatsoever. That is every camera in the list, plus six recorders — DS-7604NI-K1, DS-7604NI-K1/4P/4G, DS-7608NI-K1, DS-7608NI-K1/4G, DS-7608NI-K1/8P and DS-760NI-K1/4P. Nothing in NVD says which builds are vulnerable on a DS-2CD2043G2-I(U). Absent version data is missing information, not an assertion that every build is affected — but it means CPE matching alone will not resolve your exposure, and no amount of scanner tuning will change that.

CVE-2017-7921 has the opposite problem#

None of its 58 entries carry structured version data. The ranges exist anyway — NVD put them in the description field instead of the CPE data, so no scanner will use them. Paired with the fixed builds from ICSA-17-124-01 (retrieved 5 September 2026):

Look at the DS-2DFx row before you use any of this. Its vulnerable range runs through V5.4.5 Build 160928, and its fix is V5.4.9 Build 170123 — so generic "upgrade to 5.4.5" advice leaves that line exposed. Match the build number, not the version. ICS-CERT lists these fixed builds for North American models; if your units arrived through another region's distribution, confirm with the vendor rather than assuming the build numbers carry across.

For CVE-2021-36260 there are no fixed builds at all in the machine-readable record, and the vendor advisory returned no readable content when fetched on 5 September 2026. This page therefore does not state them.

Two of the 58 rows in the 2017 list are not models: DS-2CD63XX SERIES and DS-2DFX SERIES. They will match nothing in an inventory and will not error.

Model strings that will break your inventory join#

Before matching anything against the 2021 list, look at what is in it. Four entries are malformed in ways an automated join will drop silently and an analyst reviewing the output will not notice:

• DS-2DF5232X-AE3)T3) — mismatched parentheses
• DS-2DF6A225X-AEL)T3) — the same defect
• DS-760NI-K1/4P — a digit short, and DS-7604NI-K1/4P appears nowhere else in the list
• DS-2CD3056G2IU/SL — missing the hyphen its sibling has; both DS-2CD3056G2IU/SL and DS-2CD3056G2-IU/SL are present as separate rows

Then there is case. Eleven of the 256 are not written in the uppercase DS- form: Ptz-n2204i-de3, Ptz-n2404i-de3, Ptz-n4215-de3, Ptz-n4215i-de, Ptz-n4225i-de, Ptz-n5225i-a, IDS-2PT9A144MXS-D/T2, IDS-2SK718MXS-D, IDS-2SK8144IXS-D/J, IDS-2VS435-F840-EY and IDS-2VS435-F840-EY(T3). A case-sensitive join loses all eleven. Normalise case and strip punctuation before you match, and diff the row count before and after so you can see what the normalisation caught.

If that pushes you toward firmware strings instead of model numbers as your detection key: whether rebadged or OEM units preserve Hikvision's firmware numbering is not established here. Verify against a unit you physically hold before you rely on it.

If you cannot patch#

Sometimes you genuinely cannot — the unit is out of support, the integrator has gone quiet, or the update needs someone on a ladder. Ranked by risk removed:

1. Remove the internet exposure. Nothing else on this list comes close. It needs no vendor cooperation and no change to the device, and it is the precondition every reported exploitation path depends on.
2. Default-deny egress from the camera segment. A device that cannot reach the internet cannot fetch a second stage, which breaks the commodity botnet path even where the injection itself succeeds.
3. Deny east-west traffic from cameras to anything but the recorder, and put remote viewing behind a VPN so the vulnerable code path never receives an unauthenticated request from outside. If a VMS server sits on both the camera segment and the corporate network, this control does not hold as written — that server is the path, and it needs its own rules.
4. Treat anything previously internet-exposed as compromised until you have evidence otherwise. Patching evicts nothing. Factory reset plus reflash is the honest answer, and it is still imperfect on embedded storage.

How to check#

• Scan your external ranges from outside for HTTP and HTTPS on 80, 443, 8000 and 8080, and fingerprint what answers. A firewall rule you believe closes the exposure is not the same evidence as a scan result showing it closed.
• Read the NAT and UPnP tables on site routers, not just firewall policy. Small-business routers open ports at the device's request, and a forward created that way appears in no document you wrote.
• For the 19 recorder models above, pull the firmware version and compare directly against the ranges. That check is decisive.
• For CVE-2017-7921 on cameras, pull the V5.x.x build YYMMDD string and compare against the seven series ranges above, remembering the DS-2DFx exception.
• For CVE-2021-36260 on any camera, version matching is not available. There is no data to compare against. Exposure, not version, is your only tractable control on those 231 models — which is why removing the port forward is item one and not item four.
• Pull outbound logs for the camera segment across your longest retention window. A camera talking to anything other than the recorder, NTP or the vendor cloud is the finding worth chasing.

If that external scan turns up a camera answering from the internet, close the forward before you work through the rest of this.

Sources

1. CVE-2021-36260 detail. NIST National Vulnerability Database, 2026-06-17
2. CVE-2017-7921 detail. NIST National Vulnerability Database, 2026-06-17
3. Known Exploited Vulnerabilities Catalog — CVE-2021-36260. CISA, 2022-01-10
4. Known Exploited Vulnerabilities Catalog — CVE-2017-7921. CISA, 2026-03-05
5. Security Notification — Command Injection Vulnerability in Some Hikvision Products. Hikvision, 2021
6. ICSA-17-124-01: Hikvision Cameras. ICS-CERT, 2017-05-04
7. Experts warn of widespread exploitation involving Hikvision cameras. The Record, 2022-08-23
8. Hikvision Web Server Build 210702 Command Injection. Packet Storm, 2021
9. Hikvision IP Camera Unauthenticated Command Injection. Packet Storm, 2022

Revision history