CVE-2025-31702: What a DFIR on Dahua devices taught us

TL;DR

• During DFIR on Dahua VSS we saw devices compromised with no direct ports exposed.
• Legacy P2P flows allowed inbound tunnels based on serial-number enumeration.
• Auto-update UI could report “latest” while newer firmware existed on the website.
• We found an authenticated path-traversal → recovery-secret abuse → admin reset (CVE-2025-31702).
• Mitigate: disable P2P, update from vendor site, rotate creds, segment, vpn and monitor relay logons.

What happened?

While responding to an incident involving one of our clients’ Dahua Video Surveillance System (VSS), we discovered something weird, devices were being compromised without being direct TCP/UDP ports published to the Internet.

In addition, some devices were strongly outdated (and were compromised using the exploit for CVE-2021-33045), but others did not appear to be affected by previously reported CVEs on Dahua products. That chance ultimately allowed us to look deeper into the problem and identify some, in our opinion, concerning security findings.

One of them was recognized with CVE-2025-31702 by the vendor.

Below is a condensed version of this sometimes surprising journey, which will be expanded upon in subsequent posts.

FIRST: THE RISKS OF P2P PROTOCOL

Dahua’s proprietary EASY4IP/P2P protocol was designed to enable remote access to devices behind NAT, or firewalls, without needing to open ports.

In past firmware generations (in some kind of devices up to mid-2024), knowing a device’s serial number was sufficient to initiate a session request through Dahua’s Relay Cloud, allowing incoming tunnels to devices not directly exposed to the Internet.

Our investigation found weaknesses in S/N predictability derived from a small randomness space and in the vendor cloud relay’s rate-limiting behavior, which made it possible to enumerate valid devices with P2P enabled on a large scale and finally establish a P2P tunnel (without knowing credentials in outdated devices).

$ python dahua-sn-brute2.py [SEED]
[SEED] Trying XXXXXXXXXXXXX...
[+] S/N found: XXXXXXXXXXXXX (SEED=Y)

It is important to note the following: on devices running firmware prior to mid-2024, which does not impose password control, if P2P is enabled, it’s still possible to establish a tunnel to the device, not directly exposed to the Internet, based solely on the serial number, which can be randomly enumerated using brute force.

In our opinion, the elegant way to resolve this risk, even in poorly maintained systems, would be to introduce strict rate-limit controls in Dahua’s EASY4IP relay service, but this doesn’t seem to be the solution chosen by the vendor.

SECOND: THE NOT-SO-UPDATED UPDATE

Is your device truly up-to-date? Maybe not.

This finding was made in collaboration with Dahua’s PSIRT, following a discrepancy in the CVE reporting process.

The problem detected is as follows: the device’s web interface, with the auto-update function enabled, claimed that the device was updated to its latest version, whereas the official website had more recent firmware that was not being applied.

This matters because, as mentioned earlier, the P2P authentication fix (the one that enforces password verification) is handled by the device itself. So if the firmware isn’t actually updated, that protection simply doesn’t exist. A friendly “It is the latest version” banner can quietly extend the exposure window.

After checking with PSIRT, we learned that our main test unit was considered a customized product not eligible for cloud-based updates; something we didn’t know until they told us. That explains the mismatch, but not the behavior. Even if the device can’t be updated through the cloud, it should never report itself as “fully updated”.

From a security perspective, this is a big issue. It’s not a vulnerability in the traditional exploitable sense, but it’s still a security function that fails in the worst possible way. It gives a false sense of safety and keeps some devices running outdated firmware.

Unfortunately, we are not certain that this will be resolved in future firmware updates, although we have kindly requested that they please try to do so.

THIRD: CVE-2025-31702 – EoP IN FULLY PATCHED DEVICES

Finally, once the incident at the customer’s site had been contained (P2P disabled, accounts cleaned, passwords reset, no additional impacts confirmed and attack surface narrowed) the firmware was examined more closely because a subset of devices still showed compromise paths that didn’t match known vectors.

After a short review, a lot of reversing and some luck, we found an additional vector, an Elevation of Privilege (EoP), that can be exploited by accessing low-privileged secondary accounts such as operator, or viewer, that sometimes have weak passwords.

The EoP chain discovered is achieved abusing a low-priv authenticated path traversal to read a file containing secrets used by the password recovery mechanism. From that file, an attacker could obtain the recovery token and reset the administrator password without knowing the original.

$ python dahua-exploit.py file.asc
=== BLOB (anon.) ===
... SERIAL=ZZ0XXXXXPYY... TIMESTAMP=XXXX SEED=[REDACTED] EMAIL=user@**** ...
=== Derived (anon.) ===
MD5:[575****328d]  AuthCode: **a5c1****

We would like to thank and give credit to the great work done by midnightblue.nl by reversing and fuzzing the Lorex 2K model in November 2024, which has served us in many moments of our own research due to the similarities it shares with some of the Dahua models we have analyzed.

Affected scope

Our lab testing covered some Dahua firmware branches (2019–2024) across IPC-HFW and NVR product lines, revealing more or less consistent behavior.

Dahua PSIRT later confirmed that the following model families are impacted by CVE-2025-31702:

• IPC-1XXX Series
• IPC-2XXX Series
• IPC-WX Series
• IPC-ECXX Series
• SD3A Series
• SD2A Series
• SD3D Series
• SDT2A Series
• SD2C Series
• TPC-AEBF5201 Series
• TPC-CA Series

There may also be collateral impact on Lorex and Tiandy devices, due to firmware and protocol similarities observed during analysis. Comprehensive cross-model validation is ongoing.

Lessons to be applied

Beyond patching CVE-2025-31702 on affected devices, there are important conclusions to be drawn from this case. From a defensive standpoint, it would be very relevant to apply the following:

• Disable P2P (Settings → Network → Access Platform) unless it’s strictly necessary and always being aware of and accepting the risks.
• Apply the latest firmware from Dahua’s official website and don’t rely solely on auto-update.
• Use strong, unique credentials for all accounts, and remove unused ones.
• For business enviroments, segment your VSS in a specific devices VLAN, use VPN to remote access and block outbound EASY4IP connections to prevent accidental activation of the P2P protocol.
• Monitor your VSS for unexpected resets, privilege changes or P2P tunnel connections (127.0.0.1 logon).

Timeline & coordination

Date (2025)	Milestone
11 Mar	Issue observed during incident investigation
12 Mar	Root-cause analysis & initial P2P flaw proof-of-concept
20 Mar – 06 Jun	In-depth firmware research; authenticated path traversal and password-reset chain reproduced
25 Jun	Full disclosure report sent to Dahua PSIRT
15 Oct	Vendor advisory published and fixed builds available
29 Oct	P2P issue details disclosed
TBD	Full technical paper & exploit reproduction to follow after safe-upgrade window

Our sincere thanks to Dahua’s PSIRT for the attention, effort, and coordinated disclosure that made this CVE handling effective.

Going forward

A full write-up on the protocol reversing and exploit development will follow when doing so no longer increases risk and a secure upgrade window is in place.

Part II