CVE-2026-75490 in TR3000
Summary
by MITRE • 11/13/2026
Cudy TR3000 before 2.5.42 contains a remote code execution vulnerability that allows unauthenticated adjacent attackers to run root commands by advertising a rogue automesh controller over mDNS. Attackers on the upstream Ethernet segment can advertise _cudycmagent._tcp records pointing to a malicious MQTT broker, then send commands encrypted with a fixed AES key that router/batchcmd.lua executes as root.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/13/2026
The Cudy TR3000 wireless router, specifically versions prior to 2.5.42, suffers from a critical remote code execution vulnerability rooted in the improper handling of multicast DNS advertisements and subsequent MQTT communication channels. This flaw allows unauthenticated attackers operating on the adjacent network segment or upstream Ethernet link to gain full root-level control over the device. The attack vector exploits the router's automated mesh networking feature, which relies on mDNS for service discovery within a local area network. By advertising a rogue automesh controller using _cudycmagent._tcp records, an attacker can trick the vulnerable router into establishing a connection with a malicious MQTT broker controlled by the adversary. This mechanism bypasses traditional authentication requirements because the initial handshake and subsequent command execution rely on trust in the mDNS discovery process rather than verifying the identity of the connected service.
The technical core of this vulnerability lies in the weak cryptographic implementation used to secure communications between the router and its mesh controllers. Once a connection is established with the rogue MQTT broker, the attacker can send commands that are encrypted using a fixed AES key hardcoded within the firmware. The use of a static encryption key means that any party aware of this default credential can decrypt intercepted traffic or craft valid command payloads without needing to perform complex cryptographic attacks. These decrypted commands are then passed directly to the batchcmd.lua script running on the router's embedded Linux system. Crucially, this script executes incoming instructions with root privileges, providing the attacker with unrestricted administrative access to the device and its underlying operating system.
From an operational perspective, the impact of this vulnerability is severe, as it compromises both the confidentiality and integrity of the network infrastructure controlled by the affected routers. An adversary can execute arbitrary commands on the router, potentially leading to complete takeover of the local network segment. This could involve redirecting traffic through malicious proxies for man-in-the-middle attacks, installing persistent backdoors, or using the compromised device as a pivot point for further lateral movement into more sensitive parts of the internal network. Since the attack requires only adjacency on the Ethernet segment and no prior authentication, it poses a significant risk in environments where devices are connected to shared switches or unsecured Wi-Fi networks that bridge into wired infrastructure.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command (OS Injection) due to the execution of arbitrary commands via Lua scripts, and CWE-321 Use of a Hard-coded Cryptographic Key for its reliance on static encryption credentials. In terms of MITRE ATT&CK framework classification, this exploit maps to T1078 Valid Accounts if considering the implicit trust in mesh controllers as valid entities, but more accurately reflects T1595 Active Scanning through mDNS discovery and T1213 Data from Information Repositories for retrieving configuration details. The exploitation chain also demonstrates aspects of T1046 Network Service Discovery followed by T1059 Command and Scripting Interpreter execution via Lua scripts.
Mitigation strategies must prioritize immediate firmware updates to version 2.5.42 or later, where the vendor has presumably addressed these flaws by implementing proper authentication mechanisms for mesh controller connections and removing hardcoded encryption keys in favor of dynamic key exchange protocols such as TLS with certificate validation. In environments where updating is not immediately feasible, network segmentation should be enforced to isolate IoT devices from critical infrastructure using VLANs or firewalls that restrict mDNS traffic and MQTT ports (typically 1883) between untrusted segments and the router management interface. Additionally, disabling unused mesh features if they are not required for operational needs can reduce the attack surface by eliminating the specific service entry point exploited in this vulnerability chain.