Is CVE-2020-5735 (Amcrest Cameras and NVR Stack-based Buffer Overflow) being exploited in the wild?

What “Exploited in the Wild” Means for CVE-2020-5735

For this CVE, the practical question is not whether the flaw exists, but whether defenders should treat it as active exposure. CISA’s KEV listing is the operational signal that the issue has moved beyond theoretical risk and into confirmed exploitation, so asset owners should assume there is value in rapid verification and containment.

That matters because internet-facing cameras and NVRs often sit outside normal patching cadences, yet they remain reachable from flat networks, remote access paths, or vendor management interfaces. For a device flaw like this, the security decision is usually driven by reachability, exposure window, and whether the appliance is already part of a trusted operational path.

For practical triage, the first step is to confirm whether any Amcrest camera or NVR is exposed on port 37777 or reachable through forwarding, VPN, or remote management paths. If the device is in production, document whether it is externally reachable, whether it is segmented, and whether the management interface is limited to approved administrative hosts.

Why This Vulnerability Is Operationally Dangerous

A stack-based buffer overflow in a network appliance can do more than crash a device. In this case, an unauthenticated remote attacker may be able to trigger code execution, which turns a camera or NVR from a passive asset into a potential foothold for surveillance disruption, persistence, or pivoting inside a poorly segmented network.

This is especially important in environments that treat cameras and video recorders as low-risk infrastructure. Once a device is reachable and exploitable, its position on the network becomes the issue, not just the weakness itself. If the appliance shares trust with internal systems, a compromise can create visibility gaps and a route into adjacent infrastructure.

When the device cannot be patched immediately, the safest interim posture is to reduce exposure rather than assume the appliance is benign. That usually means restricting management access, removing unnecessary internet exposure, and treating the device as a monitored exception until remediation is complete.

What to Check Before You Decide the Risk Is Contained

Confirmation should go beyond asset discovery. Review whether the model and firmware are still in service, whether the management port is exposed anywhere beyond the intended admin network, and whether the device is already showing instability, unexpected reboots, or unusual configuration changes that could indicate abuse.

Because the flaw is pre-authentication and remotely reachable, compromise assessment should include logs, management-plane traffic, and any evidence of device tampering. Where the recorder supports it, capture configuration backups and compare them against known-good state before making changes that might erase forensic evidence.

After exposure has been reduced, rotate any credentials that may have been used to administer the device and review adjacent systems that depended on that trust path. If the NVR was integrated with other security tooling or remote access workflows, validate that those dependencies were not used to extend access elsewhere.

Risk and Threat Considerations

This kind of flaw is attractive because it targets an edge device that is often reachable, operationally important, and under-monitored. Attackers do not need valid credentials if the service is exposed, and a device crash or remote code execution can be enough to create an opening for further access or denial of service.

Failure mechanism: The vulnerable service accepts attacker-controlled input over the exposed management interface, overflows stack memory, and can crash the device or permit code execution before normal access controls ever apply.

Impact: The result can be device outage, loss of surveillance availability, and, if code execution succeeds, a foothold for further compromise in the network segment where the camera or NVR lives.

Practitioner Guidance

What to prioritise: Treat externally reachable video infrastructure as an emergency exposure class when a KEV-listed flaw exists. The decision point is not whether the device is “just a camera”, but whether it can be reached and abused from a path that attackers can realistically discover.

What to verify: Confirm the exact device inventory, the exposed service paths, and whether compensating controls actually reduce reachability. A patch plan is incomplete if the management interface remains internet-facing or available from broad internal networks.

Escalation / exception: If the device cannot be patched immediately, escalate the exception with a date, owner, and compensating controls, then keep the asset under heightened monitoring until the exposure is removed or the device is retired.

Practitioner takeaway: For KEV-listed edge-device flaws, exposure reduction is often as important as patching, because an internet-reachable appliance can become both an outage risk and an entry point before normal controls have a chance to help.

Related resources from NHI Mgmt Group

• Guide: Zero-Day and Exploited Vulnerabilities Guide
• CVE-2020-5735 (Amcrest Cameras and NVR Stack-based Buffer Overflow)
• Is CVE-2025-42599 (Qualitia Active! Mail Stack-Based Buffer Overflow) being exploited in the wild?
• Is CVE-2013-2597 (Code Aurora ACDB Audio Driver Stack-based Buffer Overflow) being exploited in the wild?
• Is CVE-2018-7445 (MikroTik RouterOS Stack-Based Buffer Overflow) being exploited in the wild?