New TP-Link Router Vulnerabilities: A Primer on Rooting Routers

At Forescout Research – Vedere Labs, we continuously investigate vulnerabilities across a wide range of connected devices, from solar inverters to programmable logic controllers. Recently, we have focused in particular on network equipment such as routers and VPN concentrators, which have become increasingly attractive targets for threat actors.

Finding new vulnerabilities requires deep inspection of devices. Yet, this is often challenging. Proprietary firmware typically lacks source code or design documentation. The software is complex. As a result, our analysis relies on debuggers, system modifications, and, ultimately, obtaining root access.

Here, we present two newly discovered vulnerabilities affecting TP-Link Omada and Festa VPN routers. Both issues allowed us to gain root privileges and served as the foundation for broader vulnerability research across additional TP-Link device families.

While our initial focus was on local exploitation to achieve “rooting” (unauthorized root access), we leveraged those privileges to analyze custom networking protocols across multiple TP-Link families. This revealed scenarios where CVE-2025-7850 could be exploited remotely without valid credentials.

Our protocol analysis also uncovered multiple, additional vulnerabilities—several of them critical and remotely exploitable. The issues are currently under coordinated disclosure with the vendor. These additional vulnerabilities are expected to be patched by Q1 2026. We will publish full details, including the extended exploitation scenarios for CVE-2025-7850, at that time.

Lastly, we discuss how similar “rooting” flaws recur across multiple networking vendors and provide guidance for researchers and manufacturers on identifying and mitigating such risks before attackers exploit them.

 

Rooting TP-Link ER605v2

Here is how the two new vulnerabilities were discovered. It began by rooting a vulnerable TP-Link Omada ER605v2 router.

Historically, the ER605v2 could be easily rooted via a hidden “debug” command accessible from the command line interface (CLI) over SSH, according to the device’s OpenWRT page. The command required an additional password derived from the current username and MAC address (Figure 1).

Figure 1 – The “debug” password derivation example (TP-Link)

This issue was reported by Cisco Talos as CVE-2024-21827, and was described as a “leftover debug code vulnerability” that allowed arbitrary command execution. After TP-Link patched it in 2024, devices could no longer be rooted this way—at least until we uncovered a new path.

CVE-2025-7851 – A Partial Patch of “Leftover Debug Code”

We began by analyzing how TP-Link fixed CVE-2024-21827. We suspected that the debug functionality might still be valuable for developers or support staff,  so it was likely not to be entirely removed.

Our analysis was confirmed: the “leftover debug code” had not been eliminated from the CLI; it was merely made harder to access. Here is what we found:

• If the /usr/sbin/image_type_debug file was present in the filesystem, the debug code functioned exactly as before.
• If not, the device presented a challenge that required signing with a specific private key (Figure 2).

Figure 2 – CVE-2025-7851 (patch changes for CVE-2024-21827)

From the point of this patch, we also discovered firmware updates were checked against the same private key. This led to who could no longer downgrade firmware.

The patch addressed CVE-2024-21827, but left two serious caveats:

1. The same private key (used across multiple devices) was required for both root access and firmware signing. Compromise of this key could have wide-reaching consequences.
2. The old “debug code” remained. If an attacker could create the “image_type_debug” file via another vulnerability or hidden feature, the original root login path could still be exploitable.

We reported this residual issue to TP-Link, which assigned it CVE-2025-7851.

However, CVE-2025-7851 alone was insufficient for us to root the ER605v2 directly: we didn’t have the private key and the “image_type_debug” file was not present in the public firmware. We needed another angle. Enter variant hunting.

Variant Hunting – Finding a New Target

Looking at prior research on TP-Link devices, we noticed that many models, including the ER605v2, use LuCI – a Lua-based framework for configuring devices via the web UI or other interfaces. LuCI is bundled with stable OpenWRT releases and widely deployed in TP-Link products.

TP-Link’s version of LuCI has a history of vulnerabilities. For example, CVE-2023-1389 was an OS command injection in TP-Link’s implementation that cybercriminals weaponized to build botnets. The flaw could be triggered with a POST request injecting arbitrary commands into the ‘country’ field (Figure 3).

Figure 3 – TP-link vulns used in a botnet (https://www.zerodayinitiative.com/blog/2023/4/21/tp-link-wan-side-vulnerability-cve-2023-1389-added-to-the-mirai-botnet-arsenal)

In 2024, Cisco Talos disclosed several more vulnerabilities in TP-Link’s LuCI implementation (Figure 4). The recurring nature of these issues suggested that the framework was a promising target for further analysis.

Consequently, we inspected the Lua files in TP-Link’s LuCI distribution, searching for overlooked weaknesses.

Figure 4 – Recurring TP-Link vulnerabilities reported by Cisco Talos (https://www.talosintelligence.com/vulnerability_reports)

A Short Aside – A Deep Dive into Lua

Note: this section presents low-level Lua details that TP-Link modified and that we had to revert to reverse engineer their files and find a new vulnerability. Less technical readers can skip to the next section: “

Lua scripts may be executed directly by the Lua Virtual Machine (LVM) or compiled for faster loading, source code protection, and offline syntax checking. LuCI ships compiled Lua files, but these are usually straightforward to decompile with off-the-shelf tools.

When we attempted to decompile TP-Link’s LuCI bytecode, common tools reported “bad headers” and other bytecode parsing errors – yet the scripts ran correctly inside TP-Link’s LuCI. The mismatch suggested TP-Link had altered both the bytecode and the LVM in ways intended to frustrate reverse engineering. Therefore, we inspected the compiled Lua files and their headers in detail.

Figure 5 – Main header format of compiled Lua files

Figure 5 exemplifies a main Lua header block. The compiled file starts with the magic bytes 1b 4c 75 61 (“\x1bLua”), followed by an octet indicating the Lua version (5.1 here). Subsequent bytes encode endianness, and the sizes of several Lua datatypes: int, size_t, instruction, and number. After the header comes the top-level function chunk – details omitted for brevity – and then one chunk per function. These function chunks include constant lists (strings, numbers, etc.) used by the function.

Figure 6 shows several examples of constants from the list.

String constants begin with the tag 04, then a length field (size given by the header’s “size of int”), followed by the value and a NUL terminator (for example, “module\x00”).

Number constants begin with the tag 03 and are followed by N bytes whose interpretation depends on the header: the 11^th byte in the header (Figure 5) defines the number size (how many octets follow), and the 12^th byte – the “integral flag” – signals whether numbers are floating point (“00”) or integer (“01”).

Figure 6 – The constant lists explained

For example, Figure 6 shows two Lua number constants: the first has the hex value “0x4030000000000000” and the second “0x10”.  Because the header’s endianness octet is “01”, both values are interpreted as little-endian. If the header’s eleventh octet indicates an 8-octet number size and the twelfth octet (the integral flag) is “00”, the first constant decodes as the 8-byte IEEE-754 floating-point value “16.0”. If instead the eleventh octet specifies a 4-octet number size, and the integral flag is “01”, the same bytes would be interpreted as a 4-byte integer with the value “16”.

To decompile TP-Link’s files, we needed to identify and normalize the vendor changes.

We compared the LuCI version bundled in TP-Link firmware with the corresponding official LuCI release and observed several nonstandard modifications (see Figure 7):

• Nonstandard integral flag: In standard Lua 5.1 the integral flag is “00” or “01”; TP-Link used an unusual value
• Replaced number tag: The typical Lua number tag “03” had been substituted with “09” in TP-Link’s bytecode. After inspection these “09” entries were just the number constants with an obfuscated tag.
• Header/number size mismatch: The header’s eleventh octet stated numbers were 8 octets long, but constants were encoded as 4-octet values.
• Nonsensical integral byte: The twelfth octet held “04”; after experimentation, we determined the constants should be interpreted as integers (“01”).

Figure 7 – Un-patching the TP-Link’s LuCI scripts

We implemented a ‘normalizer’ script to revert these changes to standard Lua bytecode conventions. After normalizing the headers and tags, decompilers produced correct output and numeric constants decoded properly. With readable Lua source, we resumed auditing LuCI for logic and input-validation issues that led to further vulnerabilities.

CVE-2025-7850 – Reopening Closed (back)doors

After reviewing TP-Link’s fixes for the issues reported by Cisco Talos (see Figure 4), we identified a variant that appeared to have been missed. The WireGuard VPN settings in the Web UI (Figure 8) expose a private-key field that is not properly sanitized, allowing an authenticated user to inject arbitrary OS commands that the device executes with root privileges.

Figure 8 – The WireGuard VPN settings in the WebUI

A decompiled fragment of the vulnerable Lua code function is shown in Figure 9.

Figure 9 – CVE-2025-7850

The root cause is subtle but straightforward: the functions “safeSpecialString()” and “normal_precheck()” – both called outside “check_key()” with the intention to escape or filter bad characters – do not remove newline characters. Because the shell treats “\n” as a command separator, an attacker can insert a newline into the private-key value to terminate the current quoted string and start a new command. Compounding this, “safeSpecialString()” returns its result wrapped in double quotes. When that quoted output is concatenated between two other double quotes (see line 211 of  “check_key())”, the first pair of quotes becomes an empty string, the content after the newline is parsed as a distinct command, and the remainder is treated as a subsequent string or command.

In the vulnerable code path, “fork_call()” at line 212 returns a value other than 1 for the crafted input; this causes the code to proceed to the “popen()” call at line 216, which executes the attacker-controlled command. An illustrative payload is shown in Figure 10.

Figure 10 – An illustrative OS command injection example for CVE-2025-7850

Exploiting this via the Web UI requires authentication, but that level of access is sufficient for our goal: rooting the device to bootstrap further analysis.

Using CVE-2025-7850 we were able to create the missing file “/usr/sbin/image_type_debug” and thereby re-enable the conventional hidden debug backdoor, which in turn allowed escalation to a root shell via the behavior described in CVE-2025-7851.

 

Beyond TP-Link: How Else to Root Routers?

Rooting a router often starts with understanding what its firmware image contains, including the underlying operating system (OS) and its component packages. Then, hunting for weak links. For many modern devices, that means inspecting Linux-based firmware, common third-party components, and vendor-specific wrappers. There are three prominent strategies researchers and vendors defending devices typically use to find root paths: exploiting historical vulnerabilities, finding recurring flaw patterns, and abusing technical support features. Let’s examine each one.

Firmware Lockdown and Historical Vulnerabilities

Today, most network devices run a Linux-based OS. OpenWRT is es and is frequently used by vendors as the base for their proprietary firmware images.

Figure 11 – OpenWRT and proprietary firmware images

Figure 11 illustrates high-level components of OpenWRT and several proprietary firmware images derived from it, including the Linux kernel and various packages. Some vendors fork OpenWRT, while other projects, such as ImmortalWRT, use the original project as a base for a different open-source distribution. In some cases, a forked firmware becomes the basis for further forks (e.g., Unitronics and MDEX firmware built on Teltonika RutOS).

Vendors modify OpenWRT in different ways. As a result, many routers are designed with OpenWRT in mind and can – officially or unofficially – be flashed with that alternative OS.

However, recent generations of devices are drifting away from this ‘freedom of choice’ for two main reasons:

1. The rise of newer Broadcom SoCs. Since the advent of WiFi 6, an increasing number of routers use Broadcom chips that OpenWRT does not support out of the box. The lack of open-source drivers (and no broad agreement to redistribute vendor drivers) forces vendors to produce vendor-specific forks that are often not open to end-users for intellectual property reasons.
2. Firmware lockdowns imposed by FCC. Since 2015, regulatory and carrier requirements intended to prevent devices from operating with non-compliant radio parameters have pushed vendors to lock down firmware. To comply, vendors adopted measures, including: firmware signing, locked bootloaders, removing end-user root access, and preventing end-users from installing alternative firmware. Although rules like those from the U.S. Federal Communications Commission target devices sold in specific markets, vendors often apply the same lockdowns globally.

These are not the only barriers to installing alternative OSes, but they matter because of the downstream effects. Many routers were designed to support OpenWRT yet have been made incapable of adoption. Creating a brand new ecosystem is unlikely given the vendor commitments and costs involved. The more consequential outcome is this: locked, forked, or binary-driver-dependent firmware tends to lag upstream updates. That lag produces a backlog of historical vulnerabilities that can remain unpatched in shipped devices. Any one of those lingering bugs may be the path to remote command execution and a full root compromise.

Last year, we studied five proprietary firmware images (four OpenWRT derivatives and one other Linux-based stack). Four of the five were running releases at least a year out of date and each contained between 12 and 30 critical historical vulnerabilities—underscoring a common and persistent problem.

Recurring Vulnerabilities

The lockdown effect also produces a second indirect consequence: recurring vulnerabilities. The surest path to rooting a device is exploiting a bug that allows arbitrary code or command execution. But finding one from scratch can be time-consuming and labor-intensive. A more efficient technique is vulnerability variant hunting: looking for new instances of a previously disclosed vulnerability in the same codebase or component.

We repeatedly observed a common pattern: researchers uncover a handful of very similar bugs in a firmware image and report them to the vendor, publishing a detailed analysis afterwards. These bugs are often traced to one or more coding or design anti-patterns: unchecked static buffers, weak input sanitization, ad hoc string concatenation into shell commands, etc. That buggy code is frequently copy and pasted, or reused in multiple places, so once you find the pattern, you can hunt a dozen near-identical bugs in one pass.

Vendors typically patch the reported issues, but they do not always perform root-cause remediation across the codebase. In a busy development cycle, teams tend to fix the immediate reported error and move on. Unfortunately, systemic faults that caused the original bugs may remain. The combination of recurring code-patterns plus partial fixes creates fertile ground for variant hunting.

For example, when we began research on Sierra Wireless and DrayTek devices, prior public reports pointed to recurring faults in common components. Sierra Wireless research highlighted repeated issues in “ACEManager” while DrayTek’s WebUI showed a history of stack buffer overflows and OS command execution vulnerabilities.

Those components are web-facing by design, so they were natural starting points for our follow-on analysis, where we again found multiple similar vulnerabilities. In DrayTek’s case, variants such as CVE-2024-41592 and CVE-2024-41585 enabled successful rooting across several models.

Because this pattern repeats so often, variant analysis should be a routine part of both vendor QA and third-party research. Vendors should treat reported bugs as symptoms of deeper issues, perform systemic root-cause analysis, and search for related instances wherever shared code or patterns exist.

Documentation and Technical Support Features

It is always worth inspecting vendor documentation, support pages, and forums. For example, Sierra Wireless documents a technical support feature called “Diagnostic Shell” (see Figure 12).

Figure 12 – Enabling the technical support feature on Sierra Wireless devices (https://source.sierrawireless.com/airlinkos/XR90-5.1/reference/system/howto/diagnosticshell/ )

Sierra Wireless devices (notably the LX60 model analyzed) do not provide end-users with direct root access. Instead, users can enable the Diagnostic Shell and then contact technical support so the vendor can resolve problems remotely.  When we inspected the implemention, we found that enabling the Diagnostic Shell permits SSH logins as root.  The root password hash is stored elsewhere in obfuscated form and copied into the “/etc/shadow” file when the setting is activated (see Figure 13).

Figure 13 – Root password hash on Sierra Wireless (partially obfuscated).

That design creates a straightforward escalation path. Anyone able to crack the stored hash can obtain root access to the device, and, potentially, to any other device that implements the same support workflow. We ultimately used a different vector to compromise the LX60, but this is a clear example of how legitimate features can be abused to root devices.

 

Conclusion and Mitigation Recommendations

The discovery of two new vulnerabilities in TP-Link Omada and Festa VPN routers: CVE-2025-7850 and CVE-2025-7851 allowed us to root the devices and study their internals. Using the root foothold, we identified multiple, additional issues, affecting other TP-Link models; those issues are in coordinated disclosure and are expected to be patched by Q1 2026, after which we will publish full technical details.

While our primary focus was on local exploitation to achieve rooting, our protocol analysis revealed scenarios where CVE-2025-7850 can be exploited without valid credentials—allowing remote command execution in some deployments. With this risk in mind, operators should treat affected devices as high priority. We recommend organizations:

• Update immediately. Apply vendor firmware updates for TP-Link Omada and Festa VPN routers, as well as any other internet-facing devices as they become available. We found the vulnerabilities on firmware version V2.6_2.1.3 (the latest at the time), but several versions are affected. See the vendor advisory for details.
• Deploy perimeter controls. Use a web application firewall (WAF) in front of web-facing management interfaces to reduce exposure to web-based vulnerabilities, such as command injections.
• Harden administrative access. Disable remote admin interfaces (SSH/HTTP) where feasible, or place them behind a VPN and strict access control lists.
• Monitor and detect. Log and monitor administrative sessions and network traffic to/from routers for anomalies and indicators of compromise and vulnerability exploitation.

The research also serves as a short primer on what it takes to bootstrap vulnerability research against routers and other embedded devices. Drawing on our own work and public reports to illustrate a practical, repeatable approaches to root network devices. This may help to uncover further critical vulnerabilities even before the full research campaign  is launched.

The strategies we describe apply broadly across IoT, OT, and IoMT devices. Many of these products run Linux or share common open-source components, so the same classes of coding and design mistakes recur. In complex firmware stacks those mistakes compound, producing hidden paths to privilege escalation or remote code execution.

Open-source and hardware modding communities often use these pathways for benign ends, for instance to increase the lifespan of their devices and make them truly their own. In the wrong hands, however, the same knowledge can enable large-scale compromise.