Talos Vulnerability Report

SUMMARY

A misconfiguration vulnerability exists in the SSH Hostkey functionality of Tp-Link AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted man-in-the-middle attack can lead to credentials leak.

CONFIRMED VULNERABLE VERSIONS

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553)

PRODUCT URLS

Archer AX53 v1.0 - https://www.tp-link.com/my/support/download/archer-ax53/

CVSSv3 SCORE

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

CWE

CWE-300 - Channel Accessible by Non-Endpoint (‘Man-in-the-Middle’)

DETAILS

The TP-Link Archer AX53 AX3000 Dual Band Gigabit Wi-Fi 6 Router is currently among the most popular routers sold online, and boasts impressive gigabit speeds for the price. This router also features remote cloud access via the TP-Link HomeShield application and smart home functionality.

The dropbear SSH service is present and running on port TCP 0.0.0.0:20001 of the TP-Link Archer AX53 device and serves to only allow port forwarding to enable remote cloud connections to the tmpServer service running on the device for app-based configuration. While it is typical for ssh server host keys to remain the same in order to prevent possible SSH connection sniffing, the TP-Link AX53 runs into a curious issue. Let us first look at the output of the mount command:

root@Archer_AX53:/tp_data# mount
ubi0:ubi_rootfs on /rom type ubifs (rw,noatime)
proc on /proc type proc (rw,noatime)
sysfs on /sys type sysfs (rw,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime,size=99028k)
tmpfs on /dev type tmpfs (rw,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,noatime,mode=600)
root on /mnt type tmpfs (rw,noatime,mode=755)
root on /overlay type tmpfs (rw,noatime,mode=755)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/worker)
ubi1:tp_data on /tp_data type ubifs (rw,relatime,sync)
ubi2:radio on /radio type ubifs (rw,relatime,sync)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)

Due to the fact that that the router utilizes UBIFS with an overlayFS, the /etc directory ends up being non-persistent. We can test this heuristically by writing a file to /etc and rebooting and seeing that the file will not exist on reboot. As such, this also applies to the /etc/dropbear/dropbear_rsa_host_key file, and we can also see this heuristically:

**** After reboot
root@Archer_AX53:# md5sum /etc/dropbear/dropbear_rsa_host_key 
87b7493a28cf5e230fc32c0107949bbc  /etc/dropbear/dropbear_rsa_host_key

root@Archer_AX53:# md5sum /tmp/dropbear/dropbear_rsa_host_key 
4c6ba311660ff77eaaa6e1e8a732c0d4  /tmp/dropbear/dropbear_rsa_host_key

root@Archer_AX53:# md5sum /rom/etc/dropbear/dropbear_rsa_host_key 
d41d8cd98f00b204e9800998ecf8427e  /rom/etc/dropbear/dropbear_rsa_host_key

root@Archer_AX53:md5sum /overlay/upper/etc/dropbear/dropbear_rsa_host_key 
87b7493a28cf5e230fc32c0107949bbc  /overlay/upper/etc/dropbear/dropbear_rsa_host_key

**** After another reboot
root@Archer_AX53:# md5sum /etc/dropbear/dropbear_rsa_host_key 
8c9b2b2a29575881b2a0948fb3532867  /etc/dropbear/dropbear_rsa_host_key

root@Archer_AX53:# md5sum /tmp/dropbear/dropbear_rsa_host_key 
dea13bb4e6bfad1eca9b85e278b4f43b  /tmp/dropbear/dropbear_rsa_host_key

root@Archer_AX53:# md5sum /overlay/upper/etc/dropbear/dropbear_rsa_host_key 
8c9b2b2a29575881b2a0948fb3532867  /overlay/upper/etc/dropbear/dropbear_rsa_host_key

root@Archer_AX53:# md5sum /rom/etc/dropbear/dropbear_rsa_host_key 
d41d8cd98f00b204e9800998ecf8427e  /rom/etc/dropbear/dropbear_rsa_host_key

We can clearly see that /etc/dropbear/dropbear_rsa_host_key matches the key found in the overlay directory as one would expect, however the contents of this file change with each router reboot. If we look at /etc/init.d/dropbear, we can also see that this key is being regenerated on each reboot:

// /etc/init.d/dropbear

start()
{
    [ -s /etc/dropbear/dropbear_rsa_host_key ] || keygen
    [ -s /etc/dropbear/dropbear_ecdsa_host_key ] || keygen_ecdsa

-------------------------------------------------------------------
keygen()
{
    local rsa2048_enable=$(uci get system.system.rsa2048_enable)
    local bits=1024
    if [ "$rsa2048_enable" == "true" ]; then
        bits=2048
    fi

    for keytype in rsa; do
        # check for keys
        key=dropbear/dropbear_${keytype}_host_key
        [ -f /tmp/$key -o -s /etc/$key ] || {
            # generate missing keys
            # mkdir -p /tmp/dropbear
            mkdir -p /tmp/dropbear/succ_cli
            [ -x /usr/bin/dropbearkey ] && {
                /usr/bin/dropbearkey -t $keytype -f /tmp/$key -s $bits 2>&- >&- && exec /etc/rc.common "$initscript" start
            } &
        #exit 0
        }
    done

    lock /tmp/.switch2jffs
    mkdir -p /etc/dropbear
    mv /tmp/dropbear/dropbear_rsa_host_key /etc/dropbear/
    lock -u /tmp/.switch2jffs
    chown root /etc/dropbear
    chmod 0700 /etc/dropbear
}

While this was most likely done to prevent the probable issue of a static RSA key vulnerability (as such a static key is found in /rom/etc/dropbear/dropbear_rsa_host_key), this configuration still does not fix the fact that the device becomes vulnerable to SSH interception issues after each reboot, until a device connects and adds the current ssh fingerprint. Thus, assuming an attacker causes the device to reboot manually via some other vulnerability or just waits until the device reboots naturally, they can then perform a Man-In-The-Middle attack on any SSH connections initiated to the device, most commonly when a user wishes to manage the device via the HomeShield phone application. This will result in the attacker gaining credentials and unauthorized configuration access to the device.

VENDOR RESPONSE

Vendor advisory: https://www.tp-link.com/us/support/faq/4943/

TIMELINE

2025-10-28 - Vendor Disclosure
2026-02-03 - Vendor Patch Release
2026-03-16 - Public Release