OS command injection in TP-Link Archer AX53 dnsmasq enables code execution

An OS command injection vulnerability in the dnsmasq module of TP-Link Archer AX53 v1.0 allows an authenticated adjacent attacker to execute arbitrary code when a specially crafted configuration file is processed due to insufficient input validation. Successful exploitation may allow the attacker to modify device configuration, access sensitive information, or further compromise system integrity. This issue affects AX53 v1.0: before 1.7.1 Build 20260213.

TP-Link identifies the affected scope as follows:

• TP-Link Archer AX53 v1.0: versions before 1.7.1 Build 20260213 are affected.
• The technical report confirmed firmware 1.3.1 Build 20241120 rel.54901(5553) as vulnerable.
• The product record uses an unaffected default status, while its explicit version condition identifies releases before 1.7.1 Build 20260213 as affected.
• TP-Link notes that AX53 v1 is not sold in the United States. Imported devices or deployments outside the United States retail channel should still be checked against the actual model and firmware.
• The available evidence does not provide a separate branch-by-branch statement for regional or parallel firmware lines beyond the stated boundary.

TP-Link Archer AX53 contains a CWE-78 flaw in the dnsmasq configuration restore functionality. The technical analysis identifies an attacker-controlled configuration value that can be passed to the --dhcp-script option as the device rebuilds the dnsmasq configuration, without sufficient input validation to neutralize dangerous content. The attacker must be authenticated and able to upload or introduce a malicious configuration file into the restore process; the device may then execute the selected script when the service starts or when a new DHCP lease is processed. At a high level, the sequence is that a malicious configuration file is accepted, its value is incorporated into dnsmasq, and a device-resident script is executed, resulting in arbitrary code execution. The available evidence identifies this component and processing path, but does not establish that every regional firmware variant or deployment configuration behaves identically.

The vulnerability is reachable from an adjacent network by an authenticated attacker; the effective vector indicates high required privileges, low attack complexity, and no user interaction. The technical analysis states that an attacker can upload a malicious file to trigger configuration processing. The supplied record marks public exploit as false, but a public technical report describes the mechanism and a tested firmware version; that does not by itself establish a weaponized public exploit. Exploitation in the wild has not been established by the supplied evidence.

The flaw can provide arbitrary code execution in the device context after a malicious configuration file is processed. Technical consequences may include router configuration changes, access to sensitive information, service-state changes, and further compromise of system integrity.

The attacker must be authenticated and able to reach the device from an adjacent network, so the evidence does not describe an unauthenticated Internet-facing attack path. Where those prerequisites exist, the effect on device confidentiality, integrity, and availability can be serious. The available evidence does not establish whether executed code can spread to other devices on the network.

Successful exploitation could let an attacker alter router configuration, change the behavior of network services, and make administrative settings unreliable. It could also expose sensitive information on the device or enable further compromise of the running system and its integrity.

Because dnsmasq provides DNS and DHCP-related functionality, control of the affected process could disrupt or alter network services on the device. The available evidence does not establish a specific effect on other hosts in the network. Practical exposure depends on whether the attacker can obtain the required credentials and reach the device from an adjacent network.

1. Identify TP-Link Archer AX53 v1.0 devices running a version before 1.7.1 Build 20260213 and install 1.7.1 Build 20260213 when that firmware is applicable to the device's model, region, and hardware revision.
2. Download firmware from TP-Link's official support page for the device's purchase region and verify the hardware version before upgrading. Do not use firmware for another model or region unless TP-Link confirms compatibility.
3. After upgrading, verify the installed firmware and review dnsmasq, DHCP, and configuration-restore settings for unexpected changes. If compromise is suspected, isolate the device and follow incident-response procedures before returning it to service.
4. The supplied record and advisory do not document a separate temporary mitigation for this issue. Until the device can be updated, restrict administrative and configuration-upload or restore access from untrusted adjacent networks as an interim precaution, not as a replacement for the fixed firmware.

1. Inventory TP-Link Archer AX53 devices and verify the hardware revision, especially devices identified as v1.0.
2. Read the installed firmware version from the management interface or asset-management system and compare it with the affected boundary in affected_summary.
3. If configuration backups are available, review them for unexpected dnsmasq settings, particularly dhcpscript values or unapproved DHCP-related changes.
4. If administrative or audit logs are available, review unexpected configuration upload, import, or restore activity. This is precautionary monitoring, not a vendor-confirmed indicator of compromise.
5. The absence of suspicious logs or configuration values does not prove that a device is safe. Verify the firmware and assess device integrity if unexpected activity is found.