Forescout’s Vedere Labs, presenting at Black Hat USA 2026, disclosed 15 vulnerabilities in the Zero-Touch Provisioning (ZTP) mechanism underlying TP-Link’s Omada line of network gear. ZTP is the “plug it in and it configures itself” protocol that lets an Omada controller automatically discover, authenticate, and provision new access points, switches, gateways, and OLT platforms without an admin touching each device. The research shows that the trust model behind that convenience is built on hardcoded secrets and weak cryptography old enough to have been broken for decades — and that the flaws chain into compromise of entire managed fleets, not just single devices.

What happened

Eleven of the 15 issues received CVE identifiers; TP-Link declined to assign CVEs to the remaining four (tracked internally as FSCT-2025-0003, FSCT-2025-0008, FSCT-2025-0011, and FSCT-2025-0014), classifying them as low severity. The findings span four impact categories: client-side code execution, information disclosure, device hijacking and spoofing, and compromise of encrypted communications.

The headline bugs:

  • CVE-2025-15627 — Omada Protocol v1 ships a hardcoded private key used to protect controller-to-device communication. Anyone who extracts the key from firmware (trivial, since it’s identical across every deployment) can impersonate a legitimate controller or decrypt captured traffic.
  • CVE-2025-15628 — Protocol v2 fares no better: a hardcoded TLS certificate and its matching private key are baked into the firmware, collapsing the certificate trust chain between controllers and clients. This enables impersonation of both local and cloud controllers and man-in-the-middle attacks across multiple TP-Link product families, not just Omada.
  • CVE-2025-15629 — The RC4 key used to encrypt v1 protocol traffic has insufficient entropy and is predictable, letting a passive network observer recover and decrypt provisioning traffic — including credentials passed during adoption.
  • CVE-2025-9291 — Devices perform insufficient Common Name validation when checking a controller’s certificate, so a spoofed controller with any certificate can pass verification and get treated as legitimate.

Beyond these four, Forescout’s broader findings include insecure transmission of device and site credentials during provisioning, a race condition in cloud-based device adoption that can let an attacker claim a device before its rightful owner, and a cross-site scripting flaw in the controller’s web management interface.

Impact

Affected products span the full Omada ecosystem: controllers (hardware, software, and cloud-hosted), gateways, switches, access points, and OLT platforms, plus the TP-Link mobile provisioning apps. Because the hardcoded-key and certificate-validation issues live in shared provisioning code, the blast radius extends beyond core Omada networking gear into other TP-Link product lines, including IP cameras and smart-home IoT devices that use the same adoption flow.

The practical attack chain: an attacker on the same broadcast domain as a device being provisioned (or one who can get in the middle of cloud-based adoption) can impersonate the controller, harvest credentials transmitted during provisioning, decrypt v1 protocol traffic outright, or race a legitimate adoption to claim a device for their own controller. Once a rogue controller has adopted a device, it can push arbitrary configuration to the entire managed fleet — turning a single weak provisioning exchange into an enterprise-wide network compromise. For managed service providers and enterprises running large Omada deployments across branch offices, this is a fleet-wide risk, not a single-device one.

Mitigation

TP-Link has shipped patches and updated advisories for a portion of the 15 issues, but has stated that remediation for some of the more structural weaknesses — the hardcoded keys and certificates baked into protocol design — won’t be complete until later in 2026, since fixing them properly requires changes beyond firmware alone. The four low-severity FSCT-tracked issues will not receive patches.

Until full fixes land:

  • Apply all available TP-Link firmware and controller updates immediately, across controllers, adopted devices, and mobile apps.
  • Avoid shared or default provisioning passwords; enforce strong, unique credentials per site and enable MFA on TP-Link ID / cloud accounts.
  • Rotate any VPN or provisioning credentials that may have transited the network prior to patching.
  • Restrict who can be on the same broadcast domain as devices being provisioned: use 802.1X, network access control, port security, Dynamic ARP Inspection, and wireless client isolation to cut off local MITM paths.
  • Segment Omada management traffic away from general user networks, and monitor for unexpected controller adoption events — a compromised provisioning flow looks like legitimate network management activity to most tooling, so treat unusual adoption timing or duplicate-device claims as an indicator of compromise.

See TP-Link’s advisory for the affected-model and firmware-version matrix, and Forescout’s Vedere Labs write-up for the full technical breakdown of all 15 issues.

Sources: Forescout Vedere Labs blog, TP-Link/Omada Networks security advisory, Help Net Security, BleepingComputer