TP-Link Tapo Cloud EUVD-2026-116270

The attacker must own a legitimate Tapo device that is authenticated to the Tapo Cloud and able to publish to the proxy topic used to request service tokens, and must know the target victim's device ID (the AT:P attack requirement). The core condition is that the broker does not verify the device ID in a proxy request matches the authenticated device, allowing issuance of a victim-scoped device token. Limiting factors: exploitation requires attacker-owned authenticated access (not fully anonymous despite the vendor's PR:N), and requires knowledge of a specific target device ID rather than being broadly sprayable. Because the flaw is in the Tapo Cloud service itself, end users cannot configure around it; TP-Link's advisory indicates the service-side fix as the remediation.

This is a server-side broken access control / missing authorization flaw (CWE-862) in TP-Link's Tapo Cloud MQTT broker, confirmed by a TP-Link advisory. The vendor CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H) scores 8.3 (High), reflecting network reach, low complexity, and high integrity and availability impact, with an attack requirement (AT:P) that maps to the need to know a victim's device ID. There is a notable conflict: the vector states PR:N (unauthenticated), yet the description explicitly requires that the attacker 'owns a Tapo device' and is an authenticated Tapo device making proxy requests - so exploitation is not truly privilege-free and this should be verified with the vendor. No EPSS score, no CISA KEV listing, and no public exploit reference are present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The vuln.today decision label is 'this_week', indicating prompt but not emergency remediation; because this is a cloud-service defect, the fix is applied server-side by TP-Link rather than by end users. Net assessment: a genuine, credibly-scored authorization flaw against a widely-used consumer cloud service, but with a meaningful precondition (device ownership plus knowledge of a target device ID) and no evidence of exploitation, placing it as a real near-term priority rather than a drop-everything emergency.

An attacker who already owns a legitimate Tapo device authenticates to the Tapo Cloud and sends a crafted proxy-topic request supplying a victim's device ID instead of their own. Because the broker never verifies that the supplied device ID belongs to the authenticated device, it issues a service token scoped to the victim's device, which the attacker uses to upload attacker-controlled content into the victim's Tapo Cloud storage so it appears in the victim's app as a legitimate event. No public exploit code is identified at time of analysis.