Cudy router flaws could allow root command execution

Cipher Security Labs has disclosed two vulnerabilities in the Cudy WR3000 router affecting hardware revision 2.0 running firmware earlier than version 2.5.24.

The flaws, tracked as CVE-2026-71960 and CVE-2026-71961, could be chained together. The first could let an attacker forge authentication for the router's MQTT broker after recovering a static signing secret from the firmware. The second could allow operating system command execution as root through the mesh management command path.

Taken together, the issues become more serious. The hard-coded signing secret could be used to create a forged JWT that passes the broker's signature check, satisfying the authenticated access requirement for the command injection flaw.

That would let an attacker move from firmware analysis to forged authentication and then to root command execution, if the relevant MQTT or mesh control interface is reachable over the network. According to the researchers, this would not require a legitimate router account, user interaction, or prior membership of the victim's local network, but it would still require network access to the management service.

CVE-2026-71960 is rated Critical with a CVSS v4 score of 9.3 and is classified as use of hard-coded credentials. CVE-2026-71961 is rated High with a CVSS v4 score of 8.7 and is classified as OS command injection.

A successful root compromise of a router can have effects beyond the device itself. Administrative control over a gateway may allow changes to DNS, firewall, routing, wireless, and mesh settings, and could support traffic redirection, persistence, disruption, or access to sensitive configuration data.

Affected scope

The published scope is limited to the Cudy WR3000 hardware revision 2.0 on firmware versions earlier than 2.5.24. The findings should not be assumed to apply to WR3000 revision 1.0, revision 3.0, or other Cudy products without separate evidence.

Cudy lists firmware version 2.5.24 for WR3000 revision 2.0. Users have been advised to check the hardware revision shown on the device or in the administration interface before installing the correct update. The researchers also recommended restricting access to MQTT and management services from untrusted networks, removing unintended port forwarding, and reviewing router settings for unexpected changes.

There is no reliable public estimate of the number of affected devices because neither manufacturer data nor vulnerability databases break down the installed base by hardware revision and firmware version. Retail availability across markets was not enough to support any numerical estimate of exposed routers.

Vendor response

The disclosure followed an exchange between the researchers and Cudy over the status of the fix in version 2.5.24. Cipher Security Labs said it downloaded the official firmware image and carried out static analysis and controlled component-level testing using authentic firmware binaries in an ARM32 emulation environment.

According to the researchers, that testing showed the JWT plugin accepted a forged token in the lab environment and that the command path returned root output. They did not complete an end-to-end exploit against a physical WR3000 revision 2.0 over the production TLS listener with a live mesh topology.

Cudy said version 2.5.24 removed the plaintext MQTT listener and added an execution permission restriction. The vendor disputed whether emulator-based results proved end-to-end exploitability on a physical device running version 2.5.24, so the researchers defined the public scope conservatively as firmware earlier than 2.5.24.

Research limits

The disclosure also highlights a recurring issue in embedded device security: the use of shared secrets inside downloadable firmware images. Once a universal signing secret is embedded in firmware, anyone who can obtain and inspect that image may be able to reproduce the authentication process intended to separate trusted management clients from unauthorised users.

For routers and other edge devices, that matters because management interfaces often sit close to core network controls. Weaknesses in authentication or input validation can turn an exposed service into a path to administrative access over the systems that handle traffic, policy, and connectivity for homes and small businesses.

"The important issue is not simply that two vulnerabilities exist in the same product," said Nir Yehoshua, Security Researcher and Co-Founder, Cipher Security Labs.

"The first vulnerability changes the trust model protecting the second. If signing material can be recovered from downloadable firmware, an attacker can reproduce the authentication that was intended to separate trusted management clients from everyone else."

Yehoshua also addressed the limits of the team's evidence for the patched version.

"Good vulnerability research includes documenting where the evidence ends," said Yehoshua.

"Our component-level testing of 2.5.24 produced security-relevant results, but it was not a physical-device end-to-end test over the production TLS path. The public scope therefore uses the conservative boundary of firmware earlier than 2.5.24 and preserves the vendor's position."

He added that the findings point to broader design questions for network devices.

"Network edge devices are security boundaries for every system behind them," said Yehoshua.

"Their management planes should be designed on the assumption that firmware can be inspected. Authentication must not depend on a universal secret, and authenticated input must never be treated as safe input when it can reach a root shell."