Root-running buffer overflow enables code execution in TP-Link Archer AX50

Stack-based buffer overflow vulnerability in the 'conn-indicator' binary running as root on the TP-Link Archer AX50 router, in firmware versions prior to 1.0.15 build 241203 rel61480. This vulnerability allows an attacker to execute arbitrary code on the device over LAN and WAN networks.

• TP-Link Archer AX50: firmware versions less than 1.0.15 build 241203 rel61480 are identified as affected.
• The normalized record marks the default status as unaffected and describes the custom version range beginning at 0 and ending before 1.0.15 build 241203 rel61480 as affected.
• Firmware version 1.0.15 build 241203 rel61480 is identified as fixed.
• The status of other models, hardware revisions, or parallel firmware branches is not established by the available evidence.

TP-Link Archer AX50 has a stack-based buffer overflow in the conn-indicator binary, which runs as root. The record states that an attacker can reach the device over LAN or WAN without prior privileges or user interaction, although exploitation has high complexity. The weakness is classified as CWE-121 and can lead to arbitrary code execution on the device. The record does not identify the specific overflowing input, protocol, request, or vulnerable code path beyond the named binary. Because the affected component runs as root, successful code execution could likely provide broad control of the router itself, but persistence and impact on other systems are not established.

The vulnerability is remotely reachable over LAN and WAN. The record indicates that no prior privileges and no user interaction are required, while the attack complexity is high. The supplied record does not identify a public exploit, and the INCIBE notice marked exploitation as No at the time of that notice. This does not establish that exploitation is currently absent, because real-world status can change.

The vulnerability can lead to arbitrary code execution on a TP-Link Archer AX50 router through the conn-indicator binary. Since that binary runs as root, successful exploitation could likely give the attacker broad control of the vulnerable device. The record assesses high impact to the device's confidentiality, integrity, and availability, while not indicating a changed security scope to another system. The practical consequences for connected networks or related systems depend on the router's configuration and access, which are not documented.

• Successful exploitation could allow arbitrary code execution and unauthorized control of a TP-Link Archer AX50 router.
• Because the vulnerable component runs as root, the attacker could potentially alter the device's operation or configuration with broad privileges.
• The record assesses high impact to the confidentiality, integrity, and availability of the device, but does not identify specific data, services, or external systems that would be affected.
• The supplied evidence does not name a victim, campaign, or specific breach.

1. Update TP-Link Archer AX50 to firmware 1.0.15 build 241203 rel61480, which is identified as the fixed version.
2. After updating, verify the actual firmware and build string on every device; do not assume that every later or parallel firmware branch has been confirmed safe.
3. If the update cannot be deployed, do not treat reduced network exposure as a confirmed fix. The record provides no specific compensating control, so the priority remains applying the fixed firmware or obtaining branch-specific guidance for the deployed device.

1. Inventory all TP-Link Archer AX50 devices deployed on internal networks and at locations reachable from WAN.
2. Check the exact firmware and build string on each device, then compare it with the affected boundary and fixed version in affected_summary.
3. Where management systems or telemetry permit, check for the presence and status of the conn-indicator binary; failure to observe the binary is not proof that the device is safe.
4. Review available telemetry for configuration changes, unexpected restarts, or unusual network behavior. Treat this as precautionary monitoring, not as a confirmed IOC for this vulnerability.
5. The supplied evidence does not provide a log signature, IOC, or specific traffic pattern.