TP-Link patches Archer NX router auth bypass that allows firmware upload

TP-Link fixed four Archer NX router flaws, including CVE-2025-15517, which lets unauthenticated attackers upload firmware. Affected versions and how to patch.

TechLogHub Engineering Team
March 25, 2026
3 min read
0 views

Share Article

TP‑Link Warns Users to Patch Critical Router Authentication Bypass Flaw

In March 2026 TP-Link released firmware for its Archer NX200, NX210, NX500 and NX600 routers that fixes four high-severity flaws. The most serious lets an unauthenticated attacker on the network reach admin-only CGI endpoints, including firmware upload. It's a textbook case of a web admin interface where some routes skipped the auth check, a bug class that turns up in far more than routers.

What happened

TP-Link's advisory (FAQ 5027) lists four CVEs, each scored under CVSS v4.0:

  • CVE-2025-15517 (8.6): certain CGI endpoints in the HTTP server lack an authentication check, so an unauthenticated attacker can perform privileged actions such as uploading firmware and changing configuration.
  • CVE-2025-15605 (8.5): a hardcoded cryptographic key in the configuration-encryption mechanism lets an authenticated attacker decrypt, edit and re-encrypt configuration files.
  • CVE-2025-15518 (8.5): command injection in the Wireless Control CLI path. Requires admin privileges.
  • CVE-2025-15519 (8.5): command injection in the Modem Management CLI path. Requires admin privileges.

The CVSS vectors for these are AV:A (adjacent network), meaning the attacker needs to be on the same network segment rather than anywhere on the internet. TP-Link says the affected products are not sold in the US. Security Affairs reported the advisory on 25 March 2026.

Who is affected

Devices running firmware below these fixed builds:

  • Archer NX600: v3.0 below 1.3.0 Build 260309; v2.0 below 1.3.0 Build 260311; v1.0 below 1.4.0 Build 260311
  • Archer NX500: v2.0 below 1.5.0 Build 260309; v1.0 below 1.3.0 Build 260311
  • Archer NX210: v3.0 below 1.3.0 Build 260309; v2.0 and v2.20 below 1.3.0 Build 260311
  • Archer NX200: v3.0 below 1.3.0 Build 260309; v2.0 and v2.20 below 1.3.0 Build 260311; v1.0 below 1.8.0 Build 260311

Consumer and small-office routers like these often go years without a firmware update, so devices installed before March 2026 should be presumed unpatched until checked.

What it means for developers and engineering teams

CVE-2025-15517 is a missing-middleware bug. Somewhere in the router's HTTP server a set of CGI handlers was registered without passing through the session check the rest of the admin UI uses. Web frameworks fail the same way when auth is opt-in per route: a new endpoint is added, the decorator or middleware is forgotten, and nobody notices because the UI never links to it unauthenticated. Default-deny routing, where every route needs auth unless explicitly marked public, plus a test that calls every route without credentials, catches this class of bug.

CVE-2025-15605 is the familiar "same key in every unit" problem. A key compiled into firmware is shared by every device of that model, so pulling it from one firmware image unlocks every config backup. The flaw needs authentication, but it turns any leaked or shared config file into something an attacker can read and modify. Device-unique keys, or keys derived from a per-device secret, avoid this.

Chained together, these flaws are serious. Unauthenticated firmware upload from the LAN means one infected laptop or a malicious guest on Wi-Fi could plant persistent malware on the router, which then sees all traffic through it. Router botnets are often built exactly this way, and two older TP-Link flaws were added to CISA's KEV catalog in 2025.

What to do now

  1. Find the hardware version on the label under the router, then download the matching firmware from TP-Link's support page for that model. Firmware for the wrong hardware revision can brick the device.
  2. Update to the fixed build (260309 or 260311 or later, per the list above) and reboot.
  3. Disable remote management from the WAN and restrict the admin UI to a wired management port or a trusted VLAN.
  4. Separate guest and IoT devices onto their own SSID or VLAN so "adjacent network" attackers are kept away from the admin interface.
  5. Change the admin password after updating, and don't share configuration backups. Assume anything encrypted with the old hardcoded key can be read.
  6. For your own web apps, add a test that enumerates every registered route and asserts a 401/403 without credentials.

Related on TechLogHub

  • Middleware: where route-level auth checks usually live
  • Authentication: default-deny vs opt-in auth
  • HTTP: background on the web admin interface involved

Sources

Stay Updated

Get the next deep dive in your inbox

Subscribe for product analysis, engineering explainers, and practical guides published on TechLogHub.

See what launched this week

One email a week: new and trending developer tools, fresh comparisons, and what shipped. Unsubscribe in one click.