Multiple critical vulnerabilities in multiple TP-Link device series

Management summary

This advisory describes several critical security vulnerabilities in various TP-Link devices. These vulnerabilities allowed an unauthenticated attacker on the same network to fully compromise the affected device. An attacker could exploit vulnerabilities in the authentication and authorization mechanisms to directly execute commands on the device with the highest privileges (root). This also made it possible to extract sensitive data from the devices and decrypt it using simple methods.

Vendor description

"Headquartered in the United States, TP-Link is a global provider of reliable networking devices and smart home products, consistently ranked as the world’s top provider of Wi-Fi devices. The company is committed to delivering innovative products that enhance people’s lives through faster, more reliable connectivity. With a commitment to excellence, TP-Link serves customers in over 170 countries and continues to grow its global footprint."

Source: https://www.tp-link.com/us/about/about-us/

Business recommendation

The vendor provides patches for multiple affected devices which should be installed immediately.

SEC Consult highly recommends to perform a thorough security review of the product conducted by security professionals to identify and resolve potential further security issues.

Vulnerability overview/description

1) Authentication Bypass (CVE-2025-30237)

The currently implemented authentication flow of the web server of the affected device makes it possible to craft special requests, which allow an attacker to directly execute certain actions on the device, without any valid user credentials. This vulnerability makes it possible to execute any action that is shown in the "Broken Access Control" vulnerability description without any authentication. Exploiting this, an attacker can effectively take over the device, given that access to the web server is possible.

2) Broken Access Control (CVE-2025-30238)

The affected device features several user profiles with different user levels. Due to insufficient checks on the device itself, an authenticated attacker can execute actions as low privileged user that are meant to be only executed as a high privileged user. An authenticated attacker can therefore create a high privileged user profile and fully take over the device by enabling SSH and logging in with the new account.

3) Sensitive Data Stored Insecurely (CVE-2025-30239)

The affected device stores sensitive data in an ineffectively protected format in multiple locations. The used symmetric cryptography makes use of hardcoded keys which are only tied to the device model. After reversing the firmware and extracting the hardcoded keys, an attacker can effectively decrypt the following files and read plaintext credentials, including the used passwords. Depending on the device configuration, CWMP provider credentials can also be extracted.

• Default Configuration (default user and Wi-Fi credentials)
• Active Configuration (all user account credentials, Wi-Fi credentials and CWMP credentials)
• Configuration Backup (all user account credentials, Wi-Fi credentials and CWMP credentials)

4) Unsafe Symbolic Link Processing (CVE-2025-30240)

The USB port on the affected device enables an attacker to place a symbolic link on USB storage devices and gain read access to the complete file system of the device.

5) Authenticated OS Command Injection (CVE-2025-30241)

Multiple input fields of the web interface are not sanitized properly and therefore allow an attacker to inject and execute arbitrary OS commands. The commands are executed with root privileges on the device, allowing to fully take over the device from the web interface.

Proof of concept

1) Authentication Bypass (CVE-2025-30237)

The authentication bypass is based on the handling of the custom transport layer encryption, which is used in HTTP and HTTPS connections. The transport layer encryption is already well known publicly, for example it is described in the following blog post: https://hex.fish/2021/05/10/tp-link-gdpr/

During authentication the following steps are executed:

1. The client requests RSA parameters and the sequence numbervia the /cgi/getParm endpoint.
2. The client provides an AES key and IV to be used for upcoming encrypted requests.

The web server of the device communicates with the client via HTTP POST "sign" and "data" parameters. The "sign" parameter is based on the following data after successful authentication:

[ redacted ]

The "data" parameter contains BASE64 encoded JSON data which is encrypted that describes the action that should be executed on the device.

For a login request the "sign" parameter looks slightly different, since the client and device need to exchange encryption parameters first. For this purpose the client provides an AES key and IV to the device via the "sign" parameter during a login request:

[ redacted ]

As an example the following "sign" parameter is valid, given that the sequence number is valid to the device.

[ redacted ]

An attacker can use the initial "sign" parameter format, with key and IV, to bypass the authentication, by replacing the "data" parameter with any action that should be executed on the device. 

For example, an attacker is able to create a "Superadmin" user on the device and enable SSH to gain full access to the device. Therefore, all examples described in issue 2 “Broken Access Control” of this advisory are now possible without any authentication.

2) Broken Access Control (CVE-2025-30238)

In order to exploit the broken access control vulnerability an attacker must be able to create or modify valid requests which follow the rules of the custom transport layer encryption that is used by the affected device. For this, an attacker only needs valid credentials for a low privileged user, who is able to log in on the web portal of the device. With a valid session an attacker can then send requests to the device, which are only meant to be performed by high privileged users on the device. This includes reading user credentials, enabling SSH or Telnet and reading CWMP credentials. The following examples show the unencrypted JSON data that can be sent to the device in the "data" parameter of a normal action POST request.

Example 1: Creating a Superadmin user

{
  "data": {
    "X_TP_Grade": "Superadmin",
    "username": "$USERNAME",
    "password": "$PASSWORD",
	[redacted]
  },
  [redacted]
  "isuseractive": true
}

Example 2: Reading User Credentials

{
  "data": {
    "stack": "0,0,0,0,0,0",
    "pstack": "0,0,0,0,0,0"
  },
  [redacted]
  "isuseractive": true
}

Example 3: Enabling SSH

{
  "data": {
    "localPort": "22",
    "sessionLifeTime": "0",
    "localEnabled": "1",
    [redacted]
  },
  [redacted]
}

3) Sensitive Data Stored Insecurely (CVE-2025-30239)

The following examples show how the different encrypted configurations and backups can be decrypted to read plaintext credentials, including the used passwords.

Example 1: Decryption of Default Configuration

The file "default_configuration.xml" contains the default user and Wi-Fi credentials in plaintext. This file is also contained in the firmware update file in the following path: 

/etc/default_configuration.xml

The configuration is encrypted using DES-ECB and a static key. The parameters for decryption are already well-known online. With the following command the default configuration can be decrypted:

[ PoC removed ]

The resulting file will contain the default plaintext credentials:

<X_TP_UserCfg>
 <RootName val=$PLAINTEXT_USERNAME />
 <RootPwd val=$PLAINTEXT_PASSWORD />
 [...]
</X_TP_UserCfg>

Example 2: Decryption of Active Configuration

The active configuration is stored at an emulated flash memory address. This file can be found in the following path:

/var/run/misc/misc_rw/0x00200000

The file itself is compressed using BriefLZ and encrypted using AES-128-CBC and a static key. The AES key and IV can be recovered by analyzing the libcmm.so and libgdpr.so binaries. The decompression step can be analyzed via the libcutil.so binary. To recover the plaintext, the header of the file (first 16 bytes) need to be discarded. After that the file can be decrypted with the following command and afterwards decompressed.

[ PoC removed ]

The BriefLZ tool (https://github.com/jibsen/brieflz) can be used for decompression after a short patch that enables RAW byte support at a specific offset (4 bytes). For this purpose the the BriefLZ function blz_depack() can be used.

The resulting file for example contains all configured user plaintext credentials:

<Users>
 <UserNumberOfEntries val=5 />
 <User instance=1 >
   <RemoteAccessCapable val=1 />
   <Username val=$PLAINTEXT_USERNAME />
   <Password val=$PLAINTEXT_PASSWORD />
[...]
</User>

Example 3: Decryption of Configuration Backup

A backup can be created in the web portal of the device. The created backup is encrypted even if no password is set by the user. The resulting file is called "conf.bin". This file is compressed and encrypted using DES-ECB with a static key that is derived from two sources. The backup encryption is already known online (https://github.com/sta-c0000/tpconf_bin_xml/blob/master/tpconf_bin_xml.py) and can be used with the correct key. The static key can be recovered if the following two parts are known:

1. Base key (static bytes embedded in the libcmm.so binary file)
2. Model key (product ID, present in a data model file)

The final key for the backup is created if both parts are XORed:

Base key  (hex) 74************cf
Model key (hex) 35************31
Final key (hex) 41************fe

Using the final key and the tool mentioned the plaintext can be recovered:

$ python tpconf_bin_xml/tpconf_bin_xml.py -o conf.bin conf.xml

The resulting XML file will contain for example the plaintext Wi-Fi credentials.

<Security>
 <ModeEnabled val=WPA2-WPA3-Personal />
 <X_TP_PSKType val=KeyPassphrase />
 <PreSharedKey val=$PRESHAREDKEY />
   <KeyPassphrase val=$PLAINTEXT_PASSWORD />
   <X_TP_WPAWPA2EncryptionMode val=AES />
</Security>

4) Unsafe Symbolic Link Processing (CVE-2025-30240)

Physical access to the device allows an attacker to use the USB port on the device. For the attacker a USB storage device needs to be NTFS formatted and a symbolic link created. The symbolic link can be created via the following command:

$ ln -s / rootfs

If the USB storage device is detected by the device, the symbolic link will be accessible via the following URL:

http:// $IP:8052/sda1/rootfs/

Under this URL the whole file system can be read, including the active configuration of the device. The active configuration is accessible via the following path:

/var/run/misc/misc_rw/0x00200000

The configuration itself is encrypted, but can be read via the proof of concept described in issue 3 "Sensitive Data Stored Insecurely".

5) Authenticated OS Command Injection (CVE-2025-30241)

As a prerequisite, authenticated access to the web interface is needed. The first vulnerable input is the content user password. It is reachable by navigating to:

Advanced -> USB Devices -> Sharing Access -> Sharing Account -> Password

To submit more characters, modification of the client-side content length check via JavaScript (maxlength="15") is needed. Subsequently, the following payload can be used to create a file in the writable data directory (you may also use the USB storage path /var/usbdisk/sda1/ to observe this, beware that there is still a length limitation of about 32 characters):

[ PoC removed ]

A reverse shell can be achieved as follows: On the attacker's computer, serve a statically compiled binary of Ncat ("nc") via TFTP and create the script “s” containing the payload:

[ PoC removed ]

Additionally, start the reverse shell listener:

$ nc -lvp 8081

On the device, execute the following payloads in a row to:

• Download the script "s" to /var
• Download the "nc" binary to /var
• Execute the script "s" to start the reverse shell:

You may need to shorten the IP to match the length limit, e.g., X.0.0.Y => X.Y.

[ PoC removed ]

The second vulnerable input identified is the WireGuard VPN username. It is reachable by navigating to:

Advanced -> VPN -> Wireguard VPN -> Account List -> Add -> Username

Similar to above, the following payload can be used to create a file:

[ PoC removed ]

Vulnerable / tested versions

The vendor TP-Link communicated the following 65 affected devices. Please refer to the solution chapter details regarding each device.

Mesh: HB Series

HB810(US2) V1.0/1.6/2.0/2.6 | HB810(EU1) V2.0     | HB710(US2) V1.6/1.0 
HB710(EU1) 1.0              | HB610(US2) V2.6/2.0 | HB610(EU1) 
HB610(CA) V2.0              | HB410( EU1) 1.0     | HB210(US2) 1.0 
HB210(EU1) 1.0              | HB210 Pro(EU1)1.0   | HB210 Pro(US2)1.0/1.6

Mesh: HX Series

HX510(US1) V2.0     | HX510(EU1) V2.0     | HX510(CA) V1.0/2.0 
HX510(AU) V1.0/2.0  | HX510(US2) 2.6      | HX710(EU1) V1.0 
HX710 Pro(EU1) V1.0 | HX220(US1) V1.0/1.0 | HX220(EU1) V1.0 
HX220(CA) V1.0      | HX220(AU) V1.0      | HX141(EU1) V1.0

Mesh: HC Series

HC220-G5(US1) V1.0/1.6 | HC220-G5(EU1) V1.20/1.0 | HC220-G5(BR) V1.30

Router: EB Series

EB210 Pro(EU1) 1.0 | EB210 Pro(US1) 1.0 | EB810v(EU1) V1.0

Router: EC Series

EC220-G5(BR) V3.0 | EC220-G5(EU1) V3.0 | EC220-G5(US1) V3.0 
EC225-G5(BR) V1.0 | EC225-G5(EU1) V1.0 | EC225-G5(US1) V1.0

Router: EX Series

EX141(BR) V1.0/1.9                | EX141(EU1) V1.0 | EX141(US1) V1.0 
EX220(BR) V1.0/1.20/1.28/1.29/1.8 | EX220(BR) V2.0  | EX220(EU1) V1.0/1.20 
EX220(RU) V1.0                    | EX220(US1) V1.0 | EX222(EU1) V1.0 
EX222(KR) V1.0                    | EX222(US1) V1.0 | EX511(BR) V2.0/2.8/2.9 
EX511(EU1) V2.0                   | EX511(US1) V2.0 | EX520(US1) V1.0 
EX520v(EU1)1.0                    | EX521(US1) V1.0 | EX820v(EU1) V1.0 
EX920(US2) V1.6/V1.0

PON: XC Series

XC220-G3v(EU1) V2.30 | XC220-G3v(US1) V2.30

PON: XX Series

XX530v(BR)v1.0 | XX530v(BR)v2.0 | XX530v(US1) 
XX530v(EU1)    | XX230v(BR) V1.0

xDSL Modem: VX Series

VX800v(DE) V1.0 | VX1800v(EU1) V1.0 | VX420-G2h(AU) V3.0

Vendor contact timeline