CVE-2026-30818
An os command injection vulnerability exists in the dnsmasq configuration restore dhcpscript functionality of Tp-Link Archer AX53 v1.0 1.3.1 Build 20241120 rel.54901(5553). A specially crafted configuration value can lead to arbitrary command execution. An attacker can upload a malicious file to trigger this vulnerability.
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)
Archer AX53 v1.0 - https://www.tp-link.com/my/support/download/archer-ax53/
9.1 - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
CWE-77 - Improper Neutralization of Special Elements used in a Command (‘Command Injection’)
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.
A long existing feature of TP-Link routers and most routers in general is the ability to backup the router configuration into a file which can then be reuploaded to the device to restore the router to a particular operational state. On the TP-Link AX3000, this functionality is accessed via the Web GUI by navigating to the ‘Advanced > System’ menu. Upon hitting the ‘Back Up’ button, the browser will download a file called ArcherAX53v120241120131n.bin. As described in a previously disclosed vulnerability on an older model of TP-Link routers https://github.com/aaronsvk/CVE-2022-30075 , this binary blob must first be decrypted with a static AES key and IV, then unpacked as a GZIP archive. After this, one must unpack the resulting tar file to get two resulting files: ori-backup-user-config.bin and ori-backup-certificate.bin with actual contents. We then unpack these two files in the same exact manner, first decrypting with the same AES key and IV and unpacking decrypted binary as a gzip file. For ori-backup-user-config.bin we end up with a config.xml file that is human readable. This configuration xml can be editied and then repacked with a reverse of the process to manually change the configuration of the device.
Among the different configuration options, there exist some that are parsed by /etc/init.d/ startup scripts, and for the purposes of this writeup we only care to look at /etc/init.d/dnsmasq:
dnsmasq() {
local cfg="$1"
append_bool "$cfg" authoritative "--dhcp-authoritative"
append_bool "$cfg" nodaemon "--no-daemon"
append_bool "$cfg" domainneeded "--domain-needed"
append_bool "$cfg" filterwin2k "--filterwin2k"
append_bool "$cfg" nohosts "--no-hosts"
append_bool "$cfg" nonegcache "--no-negcache"
append_bool "$cfg" strictorder "--strict-order"
append_bool "$cfg" logqueries "--log-queries"
append_bool "$cfg" noresolv "--no-resolv"
append_bool "$cfg" localise_queries "--localise-queries"
append_bool "$cfg" readethers "--read-ethers"
append_bool "$cfg" dbus "--enable-dbus"
append_bool "$cfg" boguspriv "--bogus-priv"
append_bool "$cfg" expandhosts "--expand-hosts"
append_bool "$cfg" enable_tftp "--enable-tftp"
append_bool "$cfg" nonwildcard "--bind-interfaces"
append_bool "$cfg" fqdn "--dhcp-fqdn"
append_parm "$cfg" dhcpscript "--dhcp-script" // [1]
// [...]
config_get_bool readethers "$cfg" readethers
[ "$readethers" = "1" -a \! -e "/etc/ethers" ] && touch /etc/ethers
echo >> $CONFIGFILE
}
This init script parses our uploaded configuration, searching for all of the above listed options among others. For this particular vulnerability it’s only worth noting that the --dhcp-script [1] is an option we can pass to dnsmasq via our configuration restoration. This option causes a script to be run on server start and also whenever a new dhcp client leases an address. As such, if we add a line to our repacked configuration as such <dhcpscript>/etc/test.sh</dhcpscript>, we can run any bash script on the file system that we want. While there may be options available to an attacker already available on the device that allow for arbitrary code execution eventually, it’s worth poionting out that the <dhcpscript> option only allows us to run a particular script, no arguments are allowed, so we cannot just spawn a dropbear server that lets us log in, we must take another step to gain arbitrary OS command execution. Thankfully, the fore mentioned ori-backup-certificate.bin lets us do just that. If we decrypt this file as mentioned above and then unpack this binary as a gzip file, we’re left with a tar archive that we can unpack to see the following files:
-rw------- 1261 2025-08-05 13:00 ./ca.crt
-rw-r--r-- 144 2025-08-05 13:00 ./client.conf
-rw------- 3707 2025-08-05 13:00 ./client.crt
-rw------- 916 2025-08-05 13:00 ./client.key
-rw------- 245 2025-08-05 13:00 ./dh1024.pem
-rw------- 3725 2025-08-05 13:00 ./server.crt
-rw------- 916 2025-08-05 13:00 ./server.key
Those with VPN knowledge will probably recognize this as common files utilized by openvpn, and we can find this same exact directory layout inside of /etc/openvpn/ on the device. It thus follows that we can unpack this tarball, add a script file of our choosing, repack the ori-backup-certificate.bin with this script file included. This tarball overwrites the contents of /etc/openvpn, and then we can run our custom script via the <dhcpscript> parameter, resulting in arbitrary OS command execution.
Vendor advisory: https://www.tp-link.com/us/support/faq/5055/
2026-01-12 - Vendor Disclosure
2026-04-08 - Vendor Patch Release
2026-05-07 - Public Release
Discovered by Lilith >_> of Cisco Talos.