Full Disclosure mailing list archives

SEC Consult SA-20261008-0 :: Multiple critical vulnerabilities in multiple TP-Link device series

From: SEC Consult Vulnerability Lab via Fulldisclosure <fulldisclosure () seclists org>
Date: Thu, 8 Oct 2026 07:07:30 +0000

SEC Consult Vulnerability Lab Security Advisory < 20261008-0 >
=======================================================================
              title: Multiple critical vulnerabilities
            product: Multiple TP-Link device series
                     Mesh: HB Series, HX Series, HC Series; Router: EB Series
                     EC Series, EX Series; PON: XC Series, XX Series;
                     xDSL modem: VX Series
 vulnerable version: Multiple affected versions
      fixed version: See solution below
         CVE number: CVE-2025-30237, CVE-2025-30238, CVE-2025-30239
                     CVE-2025-30240, CVE-2025-30241
             impact: critical
           homepage:https://www.tp-link.com
              found: 2024-12-02
                 by: Gerhard Hechenberger (Office Vienna)
                     Stefan Schweighofer (Office Vienna)
                     Constantin Schieber-Knoebl (Office Vienna)
                     SEC Consult Vulnerability Lab

                     An integrated part of SEC Consult, an Atos business
                     Europe | Asia

                     https://www.sec-consult.com

=======================================================================

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 number
     via 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:
------------------------
2024-12-19: Contacting vendor throughsecurity () tp-link com, sending
            encrypted advisory.
2024-12-27: Vendor: The vulnerabilities are currently being analyzed.
2025-01-09: Vendor: The vulnerabilities were fixed and an overview of
            the fixes is given.
2025-01-14: Asking for further information regarding other potentially
            affected devices.
2025-01-14: Vendor: The verification is in progress and source code is
            currently being reviewed for potentially other affected devices.
2025-02-04: Informing vendor that we have identified a new vulnerability (#5).
2025-02-13: Vendor provides information on how to exchange the advisory
2025-02-25: Vendor sends access information to upload portal.
2025-02-28: Uploading current advisory draft.
2025-03-18: Asking for a status update.
2025-03-19: Vendor confirms that the updated advisory draft was received
            and asks regarding the next steps. Furthermore, the vendor confirms
            that CVEs can be reserved by the SEC Consult Vulnerability Lab CNA.
2025-03-19: Asking for other affected devices and communicating the reserved CVE numbers.
2025-04-02: Vendor gives a status update regarding their internal investigation and
            provides a first list of affected devices. Furthermore, more time for
            the disclosure process is requested.
2025-04-04: Asking for more details regarding the device list and confirming that
            additional time to address these topics is in line with the disclosure
            process.
2025-04-04: Vendor confirms that the device list is a preliminary version.
2025-05-19: Asking for a status update.
2025-05-22: Vendor is currently gathering information and will share an update
            in the near future.
2025-05-30: Vendor provides info regarding fixes for additional models and custom
            firmware for affected ISPs.
2025-06-02: Asking if the communicated devices are the affected devices which
            can be added to the advisory.
2025-06-03: Vendor provides more information about the affected devices.
2025-07-10: Asking for a status update regarding the identification process.
2025-07-15: Vendor provides more information about the affected devices.
2025-07-23: Asking when the identification process will be finished.
2025-07-24: Vendor confirms that the identification process is finished and
            they are working on updates.
2025-10-08: Asking for a status update.
2025-10-10: Vendor needs more time to fix the issues and will provide an
            estimated timeline for the fixes.
2025-10-27: Vendor provides an update on the release timeline of the fixes.
            They are confident that the fixes are ready March 2026.
2026-02-05: Asking for a status update regarding the timeline/patches.
2026-02-09: Vendor R&D has released most of official firmware, still reviewing
            affected devices to avoid possible omissions. Target (March) should
            be reachable.
2026-03-05: Vendor R&D sends an update, that the release target in March is not
            reachable, as there will be fixes released for some older devices
            at the end of April.
2026-03-10: Clarifying the timeline and release process with the Vendor. Asking
            for a full list of affected products and their versions. Furthermore,
            asking if the Vendor wants to take over the CVE handling, since
            TP-Link is now an official CNA.
2026-03-13: Vendor Security Team responds that the detailed list of affected devices
            will be provided once the roll-out is completed. Vendor asks to transfer
            the already reserved CVEs to them.
2026-03-13: Asking MITRE to transfer the reserved CVEs to TP-Link.
2026-03-26: Asking MITRE for an update on the tranfer process for the CVEs.
2026-04-07: Informing the vendor that the CVE transfer process is not yet finished.
2026-04-13: MITRE confirms that the CVEIDs have been transferred to TP-Link.
2026-04-14: Informing TP-Link that the CVEIDs have now been transferred.
2026-04-15: TP-Link acknowledges the transfer of the CVEIDs.
2026-06-02: Asking for a status update regarding the timeline/patches.
2026-06-04: Vendor is currently checking information regarding the advisory
            for accurate information. CVE records and a security advisory from
            the vendor is also in preparation.
2026-07-13: Vendor confirms that the issues are prioritized and worked on. A more
            detailed update should be available in two weeks.
2026-07-23: Vendor confirms that the advisory from their side and CVEs will be
            published in the following week.
2026-07-31: Vendor clarfies that the publication date on their side will be
            delayed a few more weeks, due to further investigations.
2026-08-11: Vendor informs that investigations are completed and that the
            advisory was published. (https://www.tp-link.com/us/support/faq/5239/)
2026-10-06: Informing vendor about upcoming release. Received feedback regarding
            ISP rollout state.
2026-10-07: Informing vendor about adjustments in the advisory.
2026-10-08: Coordinated release of security advisory.


Solution:
---------
A detailed list of affected devices and the specific firmware updates that address
these vulnerabilities can found within the security advisory of the vendor:
https://www.tp-link.com/us/support/faq/5239/

CVE IDs:
https://vulnogram.org/seaview/?CVE-2025-30237
https://vulnogram.org/seaview/?CVE-2025-30238
https://vulnogram.org/seaview/?CVE-2025-30239
https://vulnogram.org/seaview/?CVE-2025-30240
https://vulnogram.org/seaview/?CVE-2025-30241


Workaround:
-----------
None


Advisory URL:
-------------
https://sec-consult.com/vulnerability-lab/


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab
An integrated part of SEC Consult, an Atos business
Europe | Asia

About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an
Atos business. It ensures the continued knowledge gain of SEC Consult in the
field of network and application security to stay ahead of the attacker. The
SEC Consult Vulnerability Lab supports high-quality penetration testing and
the evaluation of new offensive and defensive technologies for our customers.
Hence our customers obtain the most current information about vulnerabilities
and valid recommendation about the risk profile of new technologies.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Interested to work with the experts of SEC Consult?
Send us your applicationhttps://sec-consult.com/career/

Interested in improving your cyber security with the experts of SEC Consult?
Contact our local officeshttps://sec-consult.com/contact/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Mail: security-research at sec-consult dot com
Web:https://www.sec-consult.com
Blog:https://blog.sec-consult.com
X:https://x.com/sec_consult

EOF G. Hechenberger, S. Schweighofer, C. Schieber-Knoebl / @2026

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

SEC Consult SA-20261008-0 :: Multiple critical vulnerabilities in multiple TP-Link device series SEC Consult Vulnerability Lab via Fulldisclosure (Oct 15)