TP-Link Kasa cameras leaked home GPS via unauthenticated UDP for 6 years

Author: Christopher Childress (BadChemical)

Vendor: TP-Link Systems Inc. / Kasa

This repository contains proof of concept for patched vulnerabilities in TP-Link Kasa Spot EC71 indoor cameras. This information is published strictly for educational purposes and defensive research. The vendor was contacted in accordance with standard Coordinated Vulnerability Disclosure protocols on January 5, 2026. All three primary findings, fleet-wide RSA key, unsalted MD5 credential storage, and unauthenticated GPS exposure, have been remediated in v2.4.1. All device-specific identifiers, credential hashes, and global private keys have been heavily redacted to prevent abuse.

A comprehensive security analysis of the Kasa Spot EC71 revealed multiple vulnerabilities compromising the device's confidentiality, integrity, and availability. The firmware was extracted physically via a CH341A programmer reading directly from the SPI flash chip, followed by active network packet analysis and hardware analysis.

Three primary vulnerability chains, cryptographic failures, insecure credential storage, and unauthenticated exposure of precise location data, were confirmed and remediated in v2.4.1 following a multi component architectural redesign spanning six months of coordinated disclosure. The disclosure process included documented triage failures and firmware validation, resulting in a permanently bricked test device that required hardware level recovery.

The GPS exposure documented in this advisory has been publicly known since August 2020 across TP-Link's camera product line and since July 2016 for the underlying unauthenticated protocol. TP-Link remediated an identical vulnerability class in the smart plug product line in November 2020, but did not extend that remediation to the camera product line. This advisory documents a pattern of targeted, incremental remediation rather than a comprehensive architectural security review.

A secondary market attack path enables recovery of the previous owner's credentials and GPS coordinates from devices returned to factory settings.

Vendor CVSS 4.0: 8.6

Note: CVE-2026-9770 was assigned by TP-Link as CNA to cover both findings below. These represent distinct vulnerabilities with separate CWEs and independent attack paths.

CWE: CWE-321 / CWE-327

Description: The firmware contains two complete fleet wide RSA key/cert pairs across two SquashFS layers. The primary SquashFS squashfs-root contains a legacy 1024-bit RSA key/cert pair issued by TPRI-CA in 2014, expired July 2024, signed with SHA1. The secondary SquashFS layer squashfs-root-0 contains the active 2048-bit RSA key/cert pair issued by CN=TP-Link in 2021, valid until July 2031, signed with SHA256. Both key/cert pairs were confirmed coherent via public key comparison. Both are fleet wide and identical across all devices running this firmware build. The device serves the 2021 certificate at runtime. Both private keys can be extracted from SPI flash.

Impact: The active 2048-bit RSA private key in squashfs-root-0 is extractable from any EC71 unit via SPI flash and is identical across all devices running this firmware build. This key corresponds to the certificate the device serves at runtime. An attacker who extracts this key from any single device possesses the cryptographic material for the entire deployed fleet. A legacy 1024-bit key/cert pair from 2014 is also present in the primary SquashFS, but it corresponds to an expired certificate that is no longer served at runtime and has no practical exploitation value. An ARP spoofing MITM attempt against local app-to-device traffic did not intercept data, suggesting primary communication may route through the cloud. The practical exploitability of the extracted fleet-wide key for active traffic interception was not demonstrated. The vendor characterized this as "issues related to the local communication TLS certificates" in their January 16, 2026, response.

CWE: CWE-916

Description: User cloud account credentials are stored in config/account as an unsalted MD5 hash across two filesystem partitions. The read-only SquashFS filesystem contains factory default credentials (admin/admin) as placeholder values. At runtime, the jffs2 overlay overwrites this file with the authenticated user's actual TP-Link ID email address in plaintext, and the password is stored as an unsalted MD5 hash.

Cross-Domain Impact: Per TP-Link publication 'TP-Link ID offers a unified authentication service to allow you use a single email address to access the TP-Link Community, Omada Cloud, Training Systems as well as management for your TP-Link products and TP-Link Apps such as Deco, Tether, Kasa, Tapo, Aginet, Omada, and VIGI'. While each platform maintains its own interface, the TP-Link ID credentials are global. Cracking this unsalted MD5 hash is trivial with modern rainbow tables, and full hash space brute force can be achieved via GPU cluster acceleration, enabling full cross domain account takeover across all TP-Link products used by the user. This includes high-impact devices such as Tapo smart locks (remote physical access control bypass), Deco mesh network systems (full network infrastructure takeover), or VIGI commercial surveillance equipment.

CWE: CWE-359

Vendor CVSS 4.0: 5.3

Researcher CVSS 4.0: 7.1

Description: A single unauthenticated UDP packet containing {"system":{"get_sysinfo":{}}} sent to port 9999 returns a full JSON response exposing precise GPS coordinates, unique hardware identifiers (oemId, hwId, deviceId, mac, mic_mac), user-assigned device alias, and full firmware version string. This data is protected only by a trivial XOR cipher, which Wireshark natively decodes as cleartext. No authentication token, session credential, or prior device setup is required to trigger this response.

GPS coordinates are sourced from the mobile device's GPS at account creation and stored permanently in the device's firmware. They do not rotate (manual syncing is available), providing a static record of the device owner's home location.

Protocol History: The unauthenticated nature of TP-Link's Smart Home Protocol on port 9999 has been publicly documented since July 2016, when softScheck published reverse engineering research on the HS110 explicitly stating: "No authentication: Anybody on the local network can turn the Smart Plug on and off, reset it or render it inoperable." A public Python client and Wireshark dissector were released simultaneously.

Independent research published in August 2020 documented identical unauthenticated GPS coordinate exposure via port 9999 on the TP-Link KC100, a Kasa indoor pan-tilt camera. EC71 firmware built in April 2024 exhibited the same behavior on the same port using the same protocol. Standard vulnerability management practice requires identifying all products that share a vulnerable component and verifying remediation across the entire affected scope.

Note: In the 2016 softScheck publication, GPS data was labeled as an optional field. The 2020 publication contained precise coordinates; the trigger to populate the previously optional field was not identified.

GPS Storage Context: GPS coordinates are stored, protected by the overarching at-rest encryption, in config/location within the jffs2 overlay, and broadcast in cleartext via the unauthenticated get_sysinfo response regardless of device or account configuration. The Kasa geofencing beta feature launched in September 2023, three years after GPS exposure was first publicly documented. TP-Link's own geofencing documentation confirms that the feature relies on mobile device GPS rather than camera stored coordinates and requires explicit user opt-in. Despite this, GPS coordinates are collected at account creation, stored permanently in device firmware, and broadcast via an unauthenticated local network protocol regardless of whether the user has enabled or is aware of the geofencing feature.

CCPA Implications: The firmware behavior is inconsistent on three independent grounds. First, GPS coordinate collection and local network broadcast via port 9999 were publicly documented in August 2020, more than three years before the geofencing feature existed. Users who provisioned devices prior to September 2023 had no geofencing feature to enable, yet their coordinates were collected and stored. Second, GPS coordinates confirmed in config/location are present regardless of whether the user has ever enabled geofencing. Third, TP-Link's own geofencing documentation confirms the feature relies on mobile device GPS, not camera-stored coordinates, rendering the firmware's coordinate collection independent of any documented user-facing purpose.

TP-Link's Kasa Privacy Policy (last updated September 26, 2024) establishes a two tier location disclosure framework in Section 2.1. Account registration is disclosed as collecting general "location" data. Precise location, explicitly defined as "longitude and latitude", is disclosed only in the context of Geofencing enablement: 'When you enable Geofencing Smart Action, we collect or process your precise location (longitude and latitude).' The California Privacy supplement further limits geolocation disclosure to "state/country information by IP address." TP-Link's own geofencing FAQ states: "Kasa will not keep track of your geographic location, but will only send basic notification information to execute your Smart Actions when you arrive or leave home."

These coordinates, sub meter longitude and latitude, are collected at account creation and stored permanently in device firmware regardless of whether the user has enabled geofencing, placing the observed collection practice in the category that requires opt-in under the vendor's own policy framework.

Impact: Any actor on the local network can retrieve the device owner's precise home coordinates and full hardware fingerprint with a single unauthenticated UDP request. This exposure compounds with CVE-2026-9770: an attacker who obtains home coordinates via this finding can correlate them with the credential chain from Finding 2 to identify, locate, and fully compromise a specific user's smart home infrastructure, including physical access control devices.

TP-Link assigned CVE-2026-13230 a CVSS 4.0 score of 5.3 Medium with VC:L. Independent assessment rates this VC:H based on the following: precise GPS coordinates constitute sensitive personal information under CCPA explicitly defined as requiring opt in consent; sub meter location data identifies a specific residential address; the secondary market attack path confirmed in this advisory enables recovery of this data without any network access to the victim's current network; enabling property identification and interior layout correlation via public real estate databases. VC:L does not reflect the real-world privacy harm of precise home location disclosure.

TP-Link's advisory for CVE-2026-9770 characterizes the finding as a hardcoded cryptographic key vulnerability enabling credential interception. This framing omits the independent credential storage finding documented in Finding 2, unsalted MD5 hashing of TP-Link ID credentials with email address stored in plaintext, which is independently exploitable via SPI flash extraction without requiring exploitation of the RSA key or local network access. These represent distinct attack paths with distinct CWEs bundled under a single CVE at TP-Link's discretion as CNA.

The combination of findings documented in this advisory creates a compounded risk for devices that are resold, donated, or otherwise transferred to new owners. On firmware 2.3.26, returning a device to factory settings does not clear user data from jffs2 flash storage. The following attack path was confirmed on firmware 2.3.26 and is mitigated in firmware 2.4.1.

Credential Recovery via SPI Extraction: SPI flash extraction of a device returned to factory settings confirmed that the previous owner's TP-Link ID email address in plaintext and unsalted MD5 password hash remain present in config/account. An attacker can recover the previous owner's global TP-Link ID credentials without any network access or interaction with the previous owner. As documented in Finding 2, these credentials provide cross-domain account takeover across the entire TP-Link ecosystem.

GPS Exposure via Soft AP: When a device is returned to factory settings and powered on, it enters a soft AP binding mode to facilitate setup by a new owner. During this binding mode, the unauthenticated get_sysinfo request on port 9999 was confirmed to return the previous owner's precise GPS coordinates in cleartext.

Complete Secondary Market Attack Path

An attacker who purchases a secondhand EC71 can:

1. Power on the device and connect to its soft AP, retrieve the previous owner's home GPS coordinates via unauth port 9999
2. Perform SPI flash extraction, recovering the previous owner's TP-Link ID email in plaintext, MD5 password hash
3. Crack the unsalted MD5 hash via precomputed rainbow tables or GPU accelerated brute force
4. Authenticate to any TP-Link platform (Kasa, Tapo, Deco, VIGI) using the recovered credentials
5. Use the home GPS coordinates obtained in step 1 to correlate the compromised account with a physical address

The complete chain from device purchase to physical address and account compromise requires no prior knowledge of the previous owner, no network access to the previous owner's network, and no technical expertise beyond connecting to a WiFi network and running a $3 programmer.

Remediation: Firmware 2.4.1 removes GPS coordinates from the get_sysinfo response, addressing the GPS exposure path. Credential storage is encrypted via the at-rest encryption rollout in check_default_config.

The following findings were submitted to the vendor and closed under CNA Operational Rule 4.1.2 as not demonstrating a clear exploitable vulnerability, or classified as accepted risk or intended functionality.

Vendor Response: "The iot_token is used solely for device cloud authentication and has no association with user accounts. Consequently, there is no risk of device takeover via the iot_token, nor is there a risk of granting unauthorized access to live video feeds, stored clips, and device PII without the user's knowledge or the need for a password."

Researcher Rebuttal: The token is delivered to the device during provisioning and decrypted locally using an AES key. For units taking the eFuse path, key recovery requires BGA level chip analysis. On units falling back to filesystem storage, the AES key is written in plaintext to /etc/rwdir/.abcd_cfg and is fully recoverable via SPI flash extraction. The attack barrier varies significantly, depending on the provisioning path followed.

Analysis of SPI flash dumps taken approximately four months apart confirmed that iot_token and iot_refreshToken values stored in raw flash outside the jffs2 filesystem are identical across both captures. Tokens do not rotate during normal device operation and persist following a factory reset. Whether server-side revocation occurs on factory reset was not confirmed.

Packet capture analysis reveals anomalous TLS session behavior: Client Hello and Client Key Exchange packets are present with no corresponding Server Hello or Certificate response, persisting across device reboots and reprovisioning events. If the iot_token influences TLS session state, a reasonable hypothesis given its role as the primary cloud authentication vector, the accepted risk closure may warrant re-evaluation. If the token serves as the primary authorization for cloud API calls, a non-rotating token recoverable from flash storage could enable unauthorized device level access if server side authorization is not enforced per device.

Description: The production firmware contains a logical authentication bypass in /bin/login.sh activated by the $FAILSAFE environment variable, combined with a factory-burned root password hash in /etc/shadow.

#!/bin/sh
# Extracted from Kasa EC71 production firmware v2.3.26

if ( ! grep -qsE '^root:[!x]?:' /etc/shadow || \
     ! grep -qsE '^root:[!x]?:' /etc/passwd ) && \
   [ -z "$FAILSAFE" ]
then
    echo "Login failed."
    exit 0
else
    exec /bin/ash --login
fi

The $FAILSAFE condition is actively evaluated by the preinit system. Analysis of the preinit scripts confirmed three potential trigger vectors in the codebase: kernel command line injection grep -q 'failsafe=' /proc/cmdline && FAILSAFE=true, physical button press during the fs_wait_for_key window, and keypress input during the failsafe wait timeout. A command execution sink for the $FAILSAFE condition was not identified.

Vendor Response: Vendor stated login.sh is not utilized in the production codebase. Requested a functional brute-force attack to demonstrate a definitive attack path for the burned-in credentials.

Researcher Rebuttal: The vendor's 'unused' classification is inconsistent with a preinit architecture that actively evaluates and exports the $FAILSAFE environment variable via three independent mechanisms.

Regarding the burned in root password hash: shipping a static, fleet-wide credential hash in a production firmware violates PSA Certified and NIST SP 800-213 IoT security baseline requirements for unique per-device credentials. The vendor's request for a functional brute-force demonstration sets an inappropriate bar; the security failure is the presence of a static fleet wide hash, not the speed at which it can be cracked. A single offline crack of this hash compromises every EC71 unit shipping firmware v2.3.26. This hash is also present in 2.4.1.

Vendor Response: Vendor stated that the Kasa product line does not support a local web management interface, and that the findings may relate to legacy or unused code paths.

Description: Four service ports (tcp/10443, tcp/17443, tcp/18443, tcp/19443) accept TLS connections and respond to requests. The LINKIE CGI endpoint at port 10443 returns {"err_code":-1,"msg":"Bad Request"}, indicating compiled binary handler code is present in the ulinkied binary. No traffic on these ports was observed during normal operation; all camera communication routes through port 443 to the cloud infrastructure. The activation conditions and current purpose of these local ports were not fully characterized.

The Kasa Smart app launched in November 2015. Independent research published in August 2020 documented these ports as active HTTPS endpoints on the KC100. CVE-2023-28478 documented a CVSS 8.8 stack-based buffer overflow on these same ports on the hardware-identical EC70 in 2023.

Beta 2.4.1 behavior: Per-device certificates replace the fleet-wide RSA certificate. Ports 17443, 18443, and 19443 now reject connections with a TLS handshake failure alert consistent with mutual TLS authentication being required. Port 10443 continues to serve the LINKIE CGI endpoint.

Researcher Rebuttal: The vendor's January 16, 2026, response committed to remediating "issues related to the local communication TLS certificates", referring specifically to uhttpd.key and uhttpd.crt, the TLS credentials for the uhttpd web server confirmed active on ports 10443, 17443, 18443, and 19443. Dead code does not require remediation. The addition of mTLS authentication on ports 17443, 18443, and 19443 further confirms these endpoints are active infrastructure rather than legacy remnants. A vendor cannot simultaneously characterize service endpoints as unused legacy code and implement cryptographic hardening against unauthenticated access to those same endpoints.

Vendor Response: Closed under CNA Operational Rule 4.1.2.

Description: The following non-production endpoints were identified as hardcoded strings in production firmware and as active communication endpoints in network captures:

• n-devs.tplinkcloud.com
• .dcipc-beta.i.tplinkcloud.com
• tapo-care-beta.i.tplinkcloud.com

Hardcoded references to internal staging and development infrastructure in production firmware provide a map to environments that typically operate with reduced security controls. The presence of Tapo branded beta endpoints suggests convergence of backend resources across product ecosystems. The device actively communicates with these endpoints, creating a bridge between consumer devices and internal testing infrastructure.

OTA delivery bricked the test device. The factory reset was non functional. LED pattern: approximately 25 green pulses followed by one red pulse, cycling indefinitely. Vendor confirmed no software recovery path after engineering review. Device recovered via CH341A SPI reflash with original firmware 2.3.26.

Firmware diff analysis of 2.4.00 revealed the security remediation was bundled with extensive new WiFi chipset support code (WQ9001/hawk_usb). The beta certificate configuration references EC70 rather than EC71.

Note: 2.4.0 was originally grayscale deployed, aborted at 60% coverage due to 'stability issues'. The 2.4.0 version that bricked the test device was a targeted OTA after the rollback. Standard consumers do not have access to SPI flash programmers. Any affected device in the consumer deployment that experienced the same failure would have been permanently bricked without hardware level remediation.

Delivered via OTA to the replacement device alongside the beta Kasa app via TestFlight.

Confirmed remediated:

• Fleet-wide RSA: 2.4.1 removes uhttpd.key and uhttpd.crt from the firmware filesystem entirely. Per-device EC keys are provisioned through a NOC certificate infrastructure, replacing the fleetwide RSA architecture. mbedTLS upgraded from 2.6.0 to 2.28.1.

• MD5 credentials: 2.4.1 applies at rest encryption to credential storage via check_default_config encryption rollout using the device's existing AES routine.

• GPS coordinates: GPS coordinates are removed from the get_sysinfo UDP response in firmware 2.4.1. Port 9999 no longer returns a response to unauthenticated get_sysinfo requests in the patched firmware. The Kasa app broadcasts a public RSA key via UDP as part of its local device discovery architecture. This behavior is present in both firmware versions and appears to be the authenticated discovery mechanism that replaced the unauthenticated get_sysinfo response in 2.4.1.

The vendor triage response dated May 29, 2026, 66 days from disclosure, referenced "an MD5 hash in a reserved field" as the basis for low-risk classification of CVE-2026-13230. No MD5 field exists anywhere in the device's JSON response to get_sysinfo. The TPVD20260324001 tracking number breaks down into TPVD 2026 03 24 001, the day after submission, confirming the finding was correctly received and logged. The triage response describes a different vulnerability entirely. A rebuttal video demonstrating the previously provided PoC script was submitted the same day.

TP-Link's security advisory for CVE-2026-9770 and CVE-2026-13230 lists the EC70 v4 and EC71 v4 as the confirmed affected models. Independent research published in August 2020 documented identical GPS exposure on the KC100. The unauthenticated Smart Home Protocol on port 9999 documented by softScheck in 2016 affects all devices implementing this protocol. Whether the KC110, KC115, KC410S, KC411S, and other Kasa Spot Pan Tilt family devices share the vulnerable firmware codebase was not verified and is not confirmed by TP-Link's advisory. The six year documented history of this exposure across multiple hardware generations suggests the scope may extend beyond the listed models.

• softScheck, "Reverse Engineering the TP-Link HS110," July 2016 — https://www.softscheck.com/en/reverse-engineering-tp-link-hs110/
• softScheck, tplink-smartplug GitHub repository — https://github.com/softScheck/tplink-smartplug
• Medium/@hu3vjeen, "Reverse Engineering TP-Link KC100," August 2020 - https://medium.com/@hu3vjeen/reverse-engineering-tp-link-kc100-bac4641bf1cd
• CVE-2023-28478 — Stack-based buffer overflow in TP-Link EC70/EC71 local service ports, CVSS 8.8 - https://github.com/mandiant/Vulnerability-Disclosures/blob/master/2023/MNDT-2023-0006.md
• TP-Link geofencing feature documentation, September 2023 - https://community.tp-link.com/en/smart-home/stories/detail/502068
• TP-Link geofencing FAQ (Q4) - https://community.tp-link.com/us/smart-home/kb/detail/412710
• TP-Link TP Link ID - https://www.tp-link.com/us/support/faq/1439/
• TP-Link Kasa Privacy notice - https://www.tp-link.com/us/about-us/kasa-privacy/
• TP-Link Security Advisory CVE-2026-9770 / CVE-2026-13230, July 15, 2026 - https://www.tp-link.com/us/support/faq/5192/

Christopher Childress (BadChemical) — Independent IoT Security Researcher