DEV Community

Anoymask
Anoymask

Posted on

TP-Link Omada ZTP: Multiple Vulnerabilities Enabling Fleet Takeover via Device Adoption Race Conditions

#security #threatintel

TP-Link Omada ZTP: Multiple Vulnerabilities Enabling Fleet Takeover via Device Adoption Race Conditions

1. Basic Information

  • Article Title: Zero-Touch Provisioning Is a Fleet-Scale Attack Vector
  • Published By: Forescout Research – Vedere Labs
  • Publication Date: August 4, 2026
  • Original Source: Forescout
  • Related Sources: SecurityWeek, TP-Link Security Advisory
  • Related CVEs: CVE-2025-7850, CVE-2025-7851, CVE-2025-9289 through 9293, CVE-2025-15544, CVE-2025-15627 through 15631, and others
  • Related Products: TP-Link Omada controller/gateway/switch/AP/OLT/cloud/mobile app, VIGI, Festa, Tapo, Kasa
  • Severity: High

Forescout disclosed 15 vulnerabilities related to ZTP device adoption, credential processing, certificate validation, and cryptographic trust. By chaining multiple flaws, attackers can hijack cloud controllers, steal site credentials, breach internal networks, and achieve root code execution on managed devices without physical contact.

2. Summary

Attackers use predictable serial numbers and spoofed MAC addresses to win the cloud adoption race. By chaining default credentials, hard-coded keys, and weak certificate validation, they can take over controllers and connected network devices on a fleet scale.

3. Attack Flow

Chain A: Hijacking Cloud Adoption from the Internet

  1. The attacker guesses or enumerates serial numbers and spoofs MAC addresses.
  2. They send Omada Cloud adoption requests for unadopted devices before the actual owner.
  3. They exploit a race condition that can target 1,000 devices at about 17 requests per second.
  4. They hijack the device adoption process.
  5. They obtain site username/password hashes and settings using default conditions like admin/admin.
  6. They inject JavaScript into the controller web interface.
  7. They steal cloud credentials from the administrator's browser.
  8. They gain access to the cloud controller account and the internal network.
  9. They chain known RCE/root access vulnerabilities to run root commands on managed devices.

Chain B: Impersonating Controllers/Devices on the Local Network

  1. The attacker positions themselves on the same network or communication path.
  2. They abuse hard-coded keys/certificates and weak certificate validation.
  3. They impersonate a controller or device.
  4. They intercept or decrypt credentials, configurations, and encrypted traffic.
  5. Under certain conditions, they trick administrators into approving spoofed devices.
  6. They gain controller trust and push configurations and commands to the fleet.

Chain C: Spreading Across Shared Cloud Accounts

  1. The attacker compromises a TP-Link cloud account in Omada.
  2. They reach VIGI, Festa, Tapo, and Kasa products that use the same protocol and trust components.
  3. They pivot from router/network management to other ecosystems like cameras and smart homes.

4. Attacker Positioning and Execution Locations

  • External Attacker: Connects to the cloud adoption API from the Internet.
  • Adjacent Attacker: Located on the local network or communication path between the device and controller.
  • Browser-Side Execution: XSS/JavaScript in the controller web UI.
  • Cloud-Side Execution: Omada cloud account/controller privileges.
  • Device-Side Execution: Root OS commands on gateways, routers, etc.

5. What Victims and Administrators See

Administrators may notice unadopted devices linked to unexpected sites, unknown device adoptions, unexpected logins to the controller, site credential rotations, or fleet-wide configuration changes. Because protocol abuse mimics normal ZTP traffic, it is difficult to detect using simple port permissions alone. Forescout observed about 1,800 Omada controllers exposed to the Internet.

6. Success and Failure Conditions

Success Conditions

  • The target device is unadopted or in the adoption process.
  • Serial numbers and MAC addresses can be guessed.
  • The attacker can reach cloud or local ZTP traffic.
  • Default credentials, hard-coded trust, or unpatched components remain.
  • Strong privileges are concentrated in the fleet controller.

Failure Conditions

  • Controllers, devices, and mobile apps are updated to fixed versions.
  • Controllers are removed from public Internet access.
  • TP-Link IDs, sites, VPN credentials, and certificates are rotated.
  • MFA, network segmentation, and ZTP communication limits are enforced.
  • Adoption events are cross-checked with inventory to reject unknown devices.

7. What Happens on Success

Cloud controller accounts, site credentials, and device configurations are stolen. Attackers can change settings across the entire fleet of routers, switches, and APs, and execute root code. If other products share the same cloud account, the compromise spreads from network devices to cameras and other systems.

8. Observable Logs

Email

  • TP-Link cloud login, MFA, and adoption notifications.
  • Credential change notifications.

Proxy / SWG / DNS

  • Unusual ZTP traffic from controllers or devices to unexpected cloud endpoints and sources.
  • Credential submission to suspicious domains from the administrator's browser (if XSS succeeds).

Endpoint / EDR

  • Suspicious scripts on the controller origin in the administrator's browser.
  • Configuration and process changes on the controller software host.
  • Embedded devices are difficult to monitor with EDR.

Identity / IdP

  • New TP-Link ID sessions, MFA changes, site administrator additions.
  • Use of default credentials.

SaaS / Cloud

  • Device adoptions that do not match owner actions.
  • Short, repeated requests for specific serial numbers/MAC addresses.
  • Fleet-wide configuration changes from the cloud controller.

Network

  • Adoption attempts at a scale of about 17 requests per second.
  • Conflicts involving the same serial number/MAC address.
  • Unknown controller certificates or endpoints.
  • Simultaneous commands sent from the management VLAN to many devices.

9. Attack Success Evaluation

  • Contact Only: Serial enumeration / adoption failure.
  • User Interaction: Administrators approve spoofed devices in some chains.
  • Initial Execution: Device adoption hijack, controller/device impersonation.
  • Authentication Success: Login using cloud controller/site credentials.
  • Information Theft / Session Compromise: Site credentials, configuration, or cloud sessions obtained.
  • Post-Exploitation Confirmed: Fleet configuration changes, internal network access, root command execution confirmed.

10. Investigation Playbook

Trigger

  • Unknown or duplicate device adoptions.
  • Omada controllers exposed to the Internet.
  • Abnormal TP-Link ID logins.
  • Fleet-wide configuration changes.

Initial Verification

  1. Create an inventory of controller types, versions, exposure scope, and target devices.
  2. Preserve adoption, cloud account, controller, and switch/firewall logs.
  3. Compare serial numbers and MAC addresses with physical inventory.

Terminals and Devices

  • Check administrator browser history, sessions, and XSS traces.
  • Check files, processes, and network activity on the controller host.
  • Inspect device firmware, configurations, administrators, and certificates.

Authentication and Cloud

  • Check TP-Link ID sessions, MFA, roles, tokens, and site credentials.
  • Investigate VIGI, Festa, Tapo, and Kasa integrations outside of Omada.

Post-Exploitation Activities

  • Check for changes to DNS, VPN, routing, ACLs, firmware, and camera access.
  • Look for traces of root shells or command injection.
  • Treat the entire managed fleet as a single compromised unit during analysis.

Containment

  • Disconnect controllers from the Internet and isolate the ZTP segment.
  • Apply patches, rotate credentials/certificates, and enable MFA.
  • Cancel unauthorized adoptions and re-register devices from a factory-safe state.

Evaluation Categories

  • Enumeration Only
  • Adoption Hijack Confirmed
  • Controller/Cloud Account Compromised
  • Site Credentials Exposed
  • Fleet Takeover / Root Execution Confirmed

11. Defense and Detection Ideas

Single Events

  • Adoption of uninventoried serial numbers/MAC addresses.
  • Use of default admin/admin credentials.
  • Internet exposure of controllers.
  • New high-risk sessions on cloud accounts.

Timeline Correlation

Serial enumeration → adoption race → default credential access → browser XSS / cloud credential → fleet change → root execution.

Threat Hunting Perspectives

  • Adoption requests for many serial numbers from the same source.
  • Devices registered to the cloud before setup by the owner.
  • Access to other ecosystems sharing the same TP-Link cloud account.
  • Credentials and certificates remaining after firmware updates.

Log Gaps

  • ZTP protocol transactions.
  • Adoption actors and source IP addresses.
  • Embedded device command audits.
  • Cloud controller administrative audits.
  • Browser-side controller UI telemetry.

Priority Countermeasures

  1. Remove controllers from public Internet access.
  2. Apply patches to all controllers, devices, and apps.
  3. Rotate credentials, VPN secrets, and certificates.
  4. Isolate ZTP into a dedicated segment and reject unknown devices.
  5. Enable MFA on cloud accounts and maintain cross-product inventories.

12. Facts / Inference / Hypothesis

Facts

  • 15 ZTP-related vulnerabilities were disclosed, and 11 received CVE assignments.
  • A proof-of-concept demonstrated that unadopted devices can be hijacked via race conditions using spoofed MAC addresses and guessed serial numbers.
  • Attackers can chain hard-coded cryptographic material, default credentials, weak certificate validation, XSS, and known RCEs.
  • About 1,800 Omada controllers were publicly exposed on the Internet.
  • TP-Link released some patches, but fixes for structural issues are gradual.

Inference

  • Controller compromises have a larger blast radius than single router compromises, handing the entire network boundary over to the attacker.
  • Organizations must not only apply patches but also rotate site credentials and certificates that may have already been leaked.

Hypothesis

  • Linking CMDB physical device delivery/installation data with cloud adoption logs can help detect race-condition style hijacks early.

13. MITRE ATT&CK Mapping

High Confidence

  • T1190 Exploit Public-Facing Application
  • T1557 Adversary-in-the-Middle
  • T1078 Valid Accounts
  • T1059 Command and Scripting Interpreter (when root commands succeed)
  • T1021 Remote Services

Medium Confidence

  • T1557.002 ARP Cache Poisoning (specific method depends on the chain; treated as medium confidence for adjacent MITM)
  • T1098 Account Manipulation
  • T1136 Create Account
  • T1090 Proxy (if compromised routers are used as relays)
  • T1565.002 Transmitted Data Manipulation

14. Unknowns and Further Investigation

  • Exact affected versions and patch coverage for all 15 vulnerabilities.
  • Evidence of active exploitation in the wild.
  • Detailed request/response structures of the adoption API.
  • Timelines for fixing structural weaknesses marked as unpatched.
  • Number of public controllers and deployments in specific regions.
  • Real-world examples of lateral movement from Omada to other products.

15. Impact on Global SOCs and Enterprises

Omada is often used in branch offices, warehouses, and remote facilities where ZTP is managed centrally by IT operations or outsourced vendors. Organizations should treat network hardware as part of their endpoint inventory and monitor cloud accounts, controllers, and device fleets together as a single identity and management plane.

16. Summary

For SOCs

  • Correlate adoption conflicts, unknown serial numbers/MAC addresses, and fleet-wide changes.
  • Monitor beyond controllers to include TP-Link cloud accounts and related products.
  • Compensate for a lack of device logs using network and cloud audits.

For Administrators

  • Remove controllers from public Internet access and update all components.
  • Rotate credentials and certificates, and enable MFA.
  • Isolate ZTP into a dedicated network segment.

For Users

  • If a device cannot be registered or if the management screen or camera display looks unusual, do not reset the device; report it to the administrator immediately.

Top comments (0)