DVR security

What the recorder's supply chain and its remote-access defaults do to remediation, and why a DVR cannot be retired the way a camera can.

On Shodan's port snapshot of 3 September 2026, the top product string on 37777/tcp is "Dahua XVR" — a recorder.¹ Shadowserver has run a standing daily scan of 37810/UDP for years and called the output the Open DVR DHCPDiscover report.² Two of the instruments behind published video-exposure numbers are aimed, by their own labelling, at recorders.

How much of the rest is recorders, nobody has measured. No public dataset separates the two at scale, and the fingerprints that would do it — an HTTP login page, an RTSP banner — belong to both. So treat the claim that "exposed camera" counts are substantially recorders as an inference from the port evidence rather than a measurement. It matters because the two are not the same remediation problem, which is where this page ends.

A badge with no board behind it#

The board inside an unbranded recorder came from an ODM that built firmware on a silicon vendor's reference code, and the brand on the bezel may have had no hand in either — the division of labour is set out on the camera page. XiongMai is the worked example. Flashpoint found the Mirai credential root/xc3511 hardcoded into its white-labelled DVR and IP-camera boards and, on 6 October 2016, counted more than 515,000 systems showing signs of running that hardware.³ It sat behind telnet and SSH in firmware and was not feasibly changeable from the web admin panel. That story is told in full on Mirai and the camera industry; it is the case with contemporaneous reporting behind it, though the underlying scan was private research. The 2020 telnet backdoor on TCP 9530, which HiSilicon's own PSIRT scoped to HiSilicon-based DVRs and cameras and blamed on code "delivered by equipment vendors", is quantified on the firmware page.⁴

What no page carries is the shape of the segment those cases came out of. OpenIPC's processor listing catalogued 126 SoC models across 14 vendors as of 5 September 2026: SigmaStar 30, Ingenic 27, HiSilicon 23, then Goke 13, Fullhan 12 and a long tail. Eighty of the 126 come from the first three.⁵ Novatek publishes no public SoC security documentation — no secure-boot description, no OTP or signing scheme — and the same holds for SigmaStar, Ingenic, Goke and Fullhan. The substantive public material on those platforms is community reverse engineering.

For the ODM and white-label recorders built on them, no vendor security documentation could be located at all: no firmware-signing statement, no advisory page, no support window, no contact for reporting a defect. Absence of documentation is not proof the features are absent. It does mean there is no published commitment to hold a supplier to, and nowhere to send a finding.

CISA's catalogue shows the terminal state. KEV 2026.09.04 holds 1,695 entries, 83 of which carry a required action that is not to patch but to stop using the product. Among the video entries, the two NUUO NVRmini/NVRmini2 flaws and the two Reolink ones — all four added 18 December 2024 — plus D-Link's DCS-930L carry that language: actively exploited, no remedy available.⁶

A buyer can act on this before the purchase and barely at all after it. Bosch, which does publish, defines a firmware platform "mainly by the used system-on-chip (SoC)" and dates its milestones per platform rather than per model.⁷ That is the unit to ask about: which SoC, which platform, when that platform first shipped, where its advisories live. Where the model is identifiable, camerarisk.com keeps its defect history per model.

What the recorder puts on the internet#

A recorder that will be watched from a phone needs a path inbound, and there are two on offer: a forwarded port, or the vendor's cloud relay. How devices end up with the first is its own subject. What lands on the internet is largely unregistered:

Neither 37777 nor 37810 appears in the IANA registry, which is why both are vendor conventions rather than services.⁸ Their identity comes from scanning research: Censys names 37777 as Dahua's proprietary SDK and management port, and finds Amcrest strings on it because Amcrest hardware is Dahua-derived.⁹ The RTSP rows carry Modat's warning that only 56.06% of the 973,819 services it found in March 2026 sat on 554, tabulated per country on the exposure page.¹⁰ Hunt.io reached 283 Dahua devices in Operation CameraSwarm through the Easy4IP cloud relay on nothing but a serial number.¹¹ Nobody has measured how many recorders are reachable that way, so every figure in the table above undercounts by an unknown factor.

What the exploitation record shows#

GreyNoise watched exploitation attempts against TVT NVMS9000 recorders climb from 31 March 2025, peaking above 2,500 unique source IPs on 3 April and totalling more than 6,600 over the preceding 30 days, roughly triple the usual level, with enough overlap between IPs to attribute the activity to Mirai. The source IPs concentrated in Taiwan (3,637), Japan (809) and South Korea (542); those are the countries the scanning came from.¹² That is attacker interest, not exposure.

The bugs the interest rides on are cheap. CVE-2021-33044 and CVE-2021-33045 are trust-the-client logic flaws in Dahua's login handling — the CCTV page gives the actual JSON payloads — and 1,923 of the CameraSwarm devices fell to that pair.¹³ None of the 22 video entries in KEV 2026.09.04 is flagged as used in known ransomware campaigns, though whether that reflects reality or a gap in CISA's attribution data for embedded devices cannot be settled from the catalogue.¹⁴

The clearest documented ransomware involvement runs the other way round. In the Akira case S-RM investigated, the actor entered through a remote access solution, had the Windows encryptor quarantined by EDR, then found a webcam running a lightweight Linux with command execution and no endpoint agent, and ran the Linux build from there against SMB shares.¹⁵ The camera served as the execution host; entry had happened elsewhere. A recorder is the same kind of host with more disk on it.

An unsupported DVR is not an unsupported camera#

An end-of-life IP camera is a bounded problem. Segment it, deny it a default route, put a recorder or VMS in front of it, swap it one for one — every option exists because the camera is an endpoint and the recording happens elsewhere.

On a coax site the recorder is the recording, the retention, the viewing client, the account store and the only device the cameras can talk to. Segment it hard enough to be safe and the remote access it was installed to provide goes with it. Retire it and the analogue cameras go too, having no interface that speaks to anything but that chassis. The CCTV page attributes the survival of legacy coax estates to cabling economics; this asymmetry sits on top of that and pushes the same way.

The published clocks are shorter than buyers assume. Dahua's end-of-life policy, last modified 27 October 2025, commits to security updates "for at least 2 (TWO) years after the first shipment for sale of certain Dahua Products" — a clock that starts before the box reaches the buyer.¹⁶ Hikvision's equivalent commitment we could not establish: its cybersecurity pages return a JavaScript challenge rather than the document, and we will not characterise a policy we have not read. Reflashing is not a dependable fallback either, since Tarlogic found the bootloader unsigned on the Dahua DHI-NVR2104-4KS2 and DH-XVR4104HS-I, covered on the NVR page.¹⁷

Close the forward and terminate remote access somewhere that can authenticate a user. Turn off P2P registration in the device's own network settings, which the forward does not cover. None of that buys back a support window. Where the recorder is unsupported and the cameras are analogue, the remaining fix is replacing the head end, often the cabling with it — a capital line, not a patch cycle.