TP-Link prints the serial number of an Omada router on its packaging and on a label attached to the device. Those numbers run in sequence, and feeding a guessed one to the Omada cloud service returns the matching device’s MAC address and model. Serials beginning 22460J500 appear to be ER605 routers, and serials beginning 224608100 appear to be the ER7206.
Forescout’s Vedere Labs researchers built that into an attack chain, one of several they assembled from 15 vulnerabilities in Omada, TP-Link’s networking line for small and medium businesses.
An attacker who never touches the target network can end up holding the administrator’s cloud controller password, the shared password every device at a site uses, and a VPN tunnel into the internal network. Anyone running Omada routers, switches or access points is exposed. So are owners of TP-Link gear from four other product lines, which trust the same broken certificate chain.
TP-Link has published advisories and patches for most of the findings. It declined to issue CVE identifiers for four of them and rated the sequential serial number issues low severity.

What zero-touch provisioning does
Zero-touch provisioning, or ZTP, exists so a network team can unbox 150 access points and not configure them by hand. A new device comes online, finds a provisioning server called a controller, and receives its settings, credentials and firmware from it. In Omada, that controller can be a cloud service, a small appliance, or software on a virtual machine.
Central control means central failure. Compromise a controller and you inherit every device it manages. Omada groups devices into sites, and each site uses one username and password shared by all of its members, so a single credential covers a whole cluster of gear.
Controllers also sit in a privileged spot on the network, often with firewall exceptions, which makes abuse hard to spot. The Forescout report puts it in terms most defenders will recognize, describing the technique as “living off the land within network infrastructure.”
The chain, from serial number to VPN tunnel
Batch-query the cloud API for guessed serials and you have a list of MAC addresses belonging to devices that have not yet been adopted by a controller. The attacker then races the real device, spoofing only its MAC address and sending the opening adoption message ahead of it, resending every 60 seconds until the cloud answers. Vedere Labs found a high success rate in testing and estimated that working 1,000 MAC addresses at once needs roughly 17 requests per second.
Answering the cloud’s authentication challenge takes no secret at all. A new device signs it with the factory credentials admin/admin, so the attacker signs the same way. The cloud replies with the device’s configuration: the site username in cleartext, the site password as an unsalted MD5 hash, and sometimes VPN keys. Cracking the hash is optional, because the Omada protocol accepts the hash itself as proof of identity.
The impersonated device then reports its firmware version to the controller, and nothing sanitizes that string. Put JavaScript in it and it runs in the administrator’s browser. Vedere Labs used it to draw a fake session-expired login box over the Omada dashboard, sending the stolen password to an attacker-run server. From that account, the attacker configures VPN tunnels into the internal network. Once inside, a previously disclosed flaw, CVE-2025-7850, lets them run commands on Omada devices as root.
One certificate chain, five product families
The certificate work is the finding with the longest reach. Omada’s hardware and software controllers ship with a TLS certificate and private key baked into the software, and that key is what proves a controller is genuine. Pull it off one controller and you can convince client devices that your machine is theirs. Cloud connections do run an extra identity check, but swapping the controller’s hostname for its IP address skips it.
The same chain of trust sits behind VIGI cameras, Festa routers, and the Tapo and Kasa smart home lines. One set of certificates, five product families.
Scale is where the numbers matter and where they need care. Vedere Labs counts more than 1,800 Omada controllers reachable from the internet, and those are meant to be firewalled, so the figure describes misconfiguration, not normal deployment. Forescout counted 1.1 million Google Play downloads for the Omada and Omada Guard apps, and more than 70 million for the other affected TP-Link apps. Downloads are not accounts, and the researchers say only that several million active accounts are plausible. Many of those apps share one TP-Link cloud login, so a compromised Omada account may reach the linked VIGI camera deployment.
Device passwords stored on the routers themselves are MD5 hashed without salt, then encrypted with AES-256 using a key written into the source code. The key is the string who are you?.
426 days, and some of it will not be patched
Vedere Labs reported everything in June 2025 and published 426 days later. Two of the flaws cannot be fixed in firmware. On day 240, TP-Link said addressing the predictable serials and the enumeration issue would require changes to device manufacturing, packaging, factory workflows, and distributor logistics, and that remaining work might not finish before the third quarter of 2026.
Patching controllers and mobile apps is the first job, using advisories. After that, stop reusing one password across devices during provisioning, change device credentials, turn on MFA for the TP-Link ID, and rotate any VPN keys that a controller may have handed out. Local interception is what most of these attacks depend on, so 802.1X with NAC, port security, dynamic ARP inspection, wireless client isolation and segmentation all cut the attack surface directly.

Download: The ultimate guide to network operations management