One Crafted Packet, and the Cameras Go Dark: CVE-2026-29116

A fresh public proof-of-concept landed on our watch this week for a recent Dahua vulnerability that lets a remote, unauthenticated attacker reboot the device with a single crafted packet. It affects a wide swath of Dahua's line: IP cameras, PTZ domes, network video recorders, door intercoms, and access-control terminals. This is an availability attack, not code execution, but on the physical-security gear that watches critical sites, availability is the whole point.

What the vulnerability is

Dahua is one of the largest video-surveillance manufacturers in the world, and its equipment is everywhere physical security is taken seriously: perimeters, substations, pumping stations, transport hubs, plant floors, lobbies, and loading docks. CVE-2026-29116 is unusually broad because it does not affect one product, it affects a family. Dahua's advisory lists the exposed lines by their internal prefixes, and translated they are: IPC IP cameras, SD PTZ speed-dome cameras, NVR network video recorders, XVR hybrid analog and IP recorders, EVS enterprise video storage, VTO outdoor door stations, VTH indoor intercom monitors, ASI access-control terminals, and TPC thermal cameras. Affected units are specific models across those lines with firmware built before March 26, 2026.

The weakness class is a reachable assertion, CWE-617. In plain terms, the firmware contains an internal consistency check that is supposed to catch a condition that should never happen, and it treats that condition as fatal. The problem is that an attacker can deliberately create the impossible condition from the network, so a check meant to guard against a rare internal bug becomes a remote off switch. The device does exactly what it was told to do when the assertion fails, which is to stop and restart.

How the exploit works

At a conceptual level this is simpler than a memory-corruption exploit, which is part of why it is dangerous. The attacker does not need to defeat authentication, groom memory, or land a payload. They send a single malformed or unexpected message to a network service the device exposes, that message drives the firmware into a state its own code declares invalid, the assertion fires, an exception is raised, and the device reboots. As Dahua puts it in the advisory, the crafted packet triggers "an exception that causes the system to reboot unexpectedly, resulting in a denial of service." There are no credentials to steal and no session to establish, only network reach to the device.

There is no lock to pick here. A single crafted packet trips a check the firmware treats as fatal, and a camera that answered the internet a moment ago restarts itself.

We want to be precise about impact, because it shapes how you weigh this. The CVSS vector describes it exactly: high impact to availability, and none to confidentiality or integrity. An attacker cannot read your video, alter a recording, or run code on the device through this flaw. What they can do is make the device unavailable, and because the trigger is a single unauthenticated packet, they can do it repeatedly. A device stuck in a reboot loop is a camera that is not watching, a recorder that is not capturing, and a door station or access terminal that may not be answering. On surveillance and access-control hardware, that is not a minor outcome, it is the outcome the whole system exists to prevent.

Two properties make it worse than a one-off nuisance. First, it is automatable, per CISA's coordination record, which means it is the kind of condition an attacker can script against every reachable device without tuning it per target. Second, it affects a whole product family at once, so a single working packet can potentially sweep an entire mixed fleet of Dahua gear rather than a single model.

The rest of the cluster

CVE-2026-29116 did not arrive alone. It was published in Dahua's advisory DHCC-SA-202606-001 alongside related issues, and on July 11, 2026, public PoC repositories for four Dahua CVEs appeared together. We treat the unauthenticated remote reboot as the headline because it is the most exposed, but the others are worth knowing:

The pattern is what matters. CVE-2024-13985 carries the eye-catching 10.0, but it needs a hands-on-the-hardware serial connection, so its real-world blast radius is narrow. The remote, unauthenticated CVE-2026-29116 scores lower but is the one an attacker can reach across the internet without touching anything, which is why it leads our note.

Why surveillance gear lands on an OT and CI watch

We are careful about scope, so we will say it plainly: a Dahua camera is not a programmable logic controller, and this is not an ICS process-control advisory. We flag it under our operational-technology and critical-infrastructure watch for a narrower and, we think, defensible reason. Video surveillance, door intercoms, and access-control terminals are the physical-security layer of critical infrastructure. They are internet-adjacent embedded devices that live on the same sites, and often the same networks, as the equipment that actually runs a utility, a plant, or a transport system. When an attacker can blind the cameras and disturb the door terminals at a facility on demand, that is a meaningful operational effect regardless of whether the bug touches a PLC.

There is a second reason this vendor draws attention. Dahua video equipment has been the subject of sustained government scrutiny in the United States, including placement on the FCC Covered List and procurement restrictions under Section 889 of the National Defense Authorization Act, on national-security grounds. Set the policy debate aside and the practical point stands: this is widely deployed, internet-exposed, embedded gear at sensitive sites, and it has historically been a favorite target of mass-scanning botnets. A newly public, automatable way to reboot it at will is exactly the kind of development we exist to flag early.

What we see from our sensors

We run a fleet of honeypots and edge decoys, and this sits squarely in our lane. CVE-2026-29116 is reached by sending network traffic to an internet-facing embedded device, which is precisely what our decoys emulate and observe. Dahua devices typically expose a web management interface, the vendor's own TCP service historically on port 37777, and video services such as RTSP and ONVIF. Reconnaissance against them usually begins with fingerprinting those services and their banners, so bursts of probes hunting for Dahua login pages, the 37777 service, or ONVIF endpoints are a natural precursor to any attempt against this flaw.

The exploitation footprint for a denial-of-service bug is distinctive. Because the effect is an unexpected reboot, the signal is not a successful login or a dropped file, it is malformed or unexpected traffic to a device service followed by the device dropping offline and coming back. On a real fleet, clusters of Dahua units rebooting in a correlated way, especially after unusual inbound packets, are worth investigating as possible abuse of this class of flaw rather than as ordinary faults.

The exposed fleet, and what our own sensors see

Two numbers make this cluster worth more than a routine patch note: the size of the exposed population, and what the traffic against it looks like from inside a sensor network.

A July 2026 Shodan sweep for Dahua devices returns on the order of 727,000 internet-exposed systems worldwide. The exposure sits exactly where embedded surveillance gear accumulates: the vendor's proprietary service on TCP 37777, the web interface on 80 and 443, and ONVIF WS-Discovery on 3702. The largest national populations are Vietnam, Mexico, Iran, Spain, and Taiwan. The detail that should stop a defender is the last one: of those hundreds of thousands of devices, only about 74 are tagged as honeypots. The attack surface is enormous, and almost nobody is watching the Dahua-specific side of it.

The fleet is also strikingly uniform, which cuts both ways. More than 405,000 of these devices present the same WEB SERVICE web-interface title, tens of thousands carry device certificates issued by a Dahua Product Root CA (with recorder-type CNs like NVR, XVR, and HCVR), and reported firmware clusters on a handful of builds such as 3.218.x and 4.000.x. That monoculture is why a single crafted packet scales to hundreds of thousands of targets, and it is also why a decoy that reproduces those same banners is convincing: there is one look to imitate, not a thousand.

Against that backdrop, here is what our decoys actually record. Over a recent three-week window our SSH sensors logged 93,899 login attempts from 1,739 distinct source addresses. The most-sprayed camera-and-DVR default, admin/admin, was tried by 164 of them, roughly one attacker in eleven, alongside the other weak defaults this class of gear ships with: admin with a blank password, admin/admin123, admin/123456, and default/default. Those are the credentials a Dahua box leaves the factory with, and they get sprayed at anything that answers on a login port.

The more useful result is what we do not see. The signatures specific to Dahua and its OEM-DVR lineage, the hardcoded admin/7ujMko0admin and the recorder defaults root/vizxv and root/xc3511, showed up just five times in the entire window, and Dahua-specific web probes such as the /RPC2 API were essentially absent. For comparison, the loudest campaigns in that same data were hunting Linux servers and crypto-node software, not cameras. The gap is structural: Dahua-targeted campaigns speak the proprietary 37777 protocol and the device web API, not generic SSH, so unless a sensor actually looks like a Dahua recorder, the targeted traffic never reaches it. We catch the defaults that hit everyone; the Dahua-shaped attacks route around us.

That blind spot is the point. It is why our next decoy is a Dahua-styled one: a sensor that answers on 37777, presents the vendor web interface and ONVIF discovery, and carries the right banners and fingerprints, so the targeted reconnaissance and reboot attempts we currently miss finally have somewhere to land.

How to fix or mitigate it

The good news is that this is patched, so the task is exposure management and firmware hygiene rather than an emergency. Dahua's fix is delivered as updated firmware, and the practical test is the build date.

• Update the firmware, and confirm the build date. Install the current firmware for each affected model from Dahua's official download center, or use cloud upgrade where the device supports it. Do not trust model names alone, verify that each unit reports a build date on or after March 26, 2026.
• Get these devices off the public internet. Surveillance and access-control gear should almost never be directly reachable from the internet. Put cameras, recorders, intercoms, and access terminals behind the firewall on a dedicated segment, and reach them through a VPN rather than by exposing the web interface or the 37777 service.
• Segment the physical-security network. Keep the surveillance and access-control VLAN separated from both corporate IT and any OT process network. A reboot attack that can only be launched from inside a tightly scoped segment is a far smaller problem than one exposed to the whole internet.
• Watch for the pattern, not just the patch. Alert on correlated, unexpected reboots across Dahua devices and on unusual inbound traffic to their management and video services. Availability abuse looks like devices flapping, so make device-uptime and reboot events something your monitoring actually surfaces.
• Inventory the whole family. Because this spans nine product lines, the forgotten devices are the risk: an old XVR in a back room, a door station at a remote gate, a thermal camera on a perimeter. Find every Dahua unit before you decide you are covered.

Indicators and references