TP-Link Kasa Spot EC71 (Firmware 2.3.26) GPS Leak and Hardcoded RSA Keys – Full Disclosure and Vendor Response

TP-Link Kasa Spot EC71 (Firmware 2.3.26) GPS Leak and Hardcoded RSA Keys – Full Disclosure and Vendor Response

TL;DR

The TP‑Link Kasa Spot EC71 camera (firmware 2.3.26) leaked a device’s exact GPS location and a fleet‑wide RSA private key to anyone on the local network via a single unauthenticated UDP packet, and stored user passwords as unsalted MD5 hashes. TP‑Link patched all three issues in firmware 2.4.1 after a six‑month coordinated‑disclosure effort that included a bricked test device and a faulty factory‑reset process.

1. Core Findings – What Was Broken and Why It Matters

1.1 Unauthenticated GPS Exposure (CVE‑2026‑13230)

A UDP packet to port 9999 containing {"system":{"get_sysinfo":{}}} returns a clear‑text JSON payload that includes:

  • Precise latitude/longitude (sub‑meter accuracy) stored at account creation
  • Hardware identifiers (oemId, hwId, deviceId, MAC addresses)
  • User‑assigned device alias and full firmware version The response is only XOR‑obfuscated; Wireshark decodes it automatically. No authentication token, session cookie, or prior pairing is required.

Impact: Any attacker on the same LAN can harvest a homeowner’s exact address and a unique device fingerprint with a single packet. The coordinates are static (they do not rotate) and are stored in config/location on the device’s JFFS2 overlay, persisting across factory resets.

1.2 Fleet‑Wide RSA Private Key (CVE‑2026‑9770)

The firmware contains two complete RSA key/certificate pairs in separate SquashFS layers:

  • A legacy 1024‑bit key (expired 2024) – not used at runtime.
  • An active 2048‑bit key (valid until 2031) that the device presents during TLS handshakes. Both private keys are extractable from the SPI flash of any EC71 unit and are identical across the entire fleet.

Impact: Possession of the active private key enables a man‑in‑the‑middle attacker to forge TLS sessions that the device trusts, potentially decrypting or injecting traffic to the cloud service.

1.3 Insecure Credential Storage (Finding 2, part of CVE‑2026‑9770)

User TP‑Link ID credentials are stored in config/account as:

  • Plain‑text email address
  • Unsalted MD5 hash of the password The hash is trivially cracked with rainbow tables or GPU‑accelerated brute force, giving the attacker the same credentials across the entire TP‑Link ecosystem (Kasa, Tapo, Deco, VIGI, etc.).

Impact: Compromise of a single camera yields global account takeover, including high‑value devices such as smart locks and mesh routers.

2. Historical Context – How Long the Vulnerability Existed

  • July 2016: SoftScheck published the first reverse‑engineering of TP‑Link’s Smart Home Protocol, noting that the protocol on port 9999 had no authentication.
  • August 2020: Independent research on the KC100 camera documented the same unauthenticated GPS leak.
  • July 2020 – July 2024: TP‑Link’s own smart‑plug firmware was patched for the unauthenticated protocol, but the camera line never received the fix.
  • September 2023: TP‑Link introduced a geofencing feature that uses the mobile device’s GPS, yet the camera continued to collect and broadcast its own GPS coordinates regardless of user opt‑in.
  • January 2026: The researcher disclosed the three findings to TP‑Link, initiating a coordinated‑disclosure process.
  • July 2026: TP‑Link released firmware 2.4.1, fixing all three findings and issuing CVE‑2026‑9770 and CVE‑2026‑13230.

3. Coordinated Disclosure Timeline – Vendor Interaction

Date Milestone
Jan 5 2026 Initial advisory sent
Jan 16 2026 Vendor requests PoC scripts; commits to fixing TLS‑certificate issues
Mar 23 2026 Vendor asks for extension to redesign architecture
Jun 5 2026 Vendor requests open‑ended extension for GPS disclosure – denied
Jun 15 2026 Beta firmware 2.4.00 OTA bricks test device (no software recovery)
Jun 24 2026 Beta firmware 2.4.1 delivered to replacement device
Jul 14 2026 Public advisory and CVE issuance

The timeline shows multiple triage failures: the May 29 2026 triage response referenced a non‑existent MD5 field, and the vendor repeatedly mis‑characterized the GPS leak as low‑risk.

4. Secondary‑Market Attack Path – Why Resold Devices Are Dangerous

  1. Power on a second‑hand EC71 and connect to its soft‑AP.
  2. Send the unauthenticated UDP get_sysinfo request – the response reveals the previous owner’s GPS coordinates.
  3. Extract the SPI flash (≈$3 programmer) – the config/account file still contains the prior owner’s email (plain text) and MD5 password hash.
  4. Crack the MD5 hash (rainbow tables or GPU).
  5. Use the recovered credentials to log into any TP‑Link service (Kasa, Tapo, Deco, VIGI).
  6. Correlate the compromised account with the GPS location obtained in step 2.

All steps require only physical access to the device and a local network connection; no knowledge of the previous owner is needed. Firmware 2.4.1 removes the GPS data from the UDP response and encrypts credential storage, breaking this chain.

5. Vendor Remediation – What Changed in Firmware 2.4.1

  • RSA Keys: Fleet‑wide uhttpd.key/uhttpd.crt removed; per‑device certificates provisioned via a NOC infrastructure; mbedTLS upgraded from 2.6.0 → 2.28.1.
  • Credential Storage: check_default_config now encrypts the config/account file; MD5 hashes are no longer used.
  • GPS Leak: get_sysinfo UDP endpoint on port 9999 no longer responds; GPS coordinates are no longer broadcast locally.
  • Local Service Ports: Ports 17443, 18443, 19443 now require mutual TLS; port 10443 continues to serve a LINKIE CGI endpoint but is no longer used for device management.

6. Independent CVSS Assessment – Why the Vendor’s Scores Understate Risk

  • CVE‑2026‑13230: TP‑Link assigned CVSS 5.3 (Medium, Confidentiality Low). Independent analysis rates it CVSS 7.1 (High) because precise location data is classified as sensitive personal information under CCPA and the leak occurs without any authentication.
  • CVE‑2026‑9770: Vendor’s CVSS 8.6 focuses on TLS‑certificate misuse, but the unsalted MD5 credential storage provides a separate, high‑impact attack vector that is not reflected in the single CVE.

7. Community Reaction – Highlights from Hacker News Discussion

"This underscores the principle that IoT devices should not be allowed to communicate over the public Internet." – drnick1

"The fact that a firmware upgrade bricked the camera doesn’t bode well for their other products..." – nubinetwork

"Six months of coordinated disclosure… a beta patch that permanently bricked my test device, and a factory reset that doesn’t clear previous owner data." – BadChemical (researcher)

These comments reflect broader concerns about the reliability of OTA updates and the need for secure default behaviors in consumer IoT.

8. Lessons Learned and Recommendations

  1. Never trust unauthenticated local protocols. Even a simple UDP request can expose sensitive data.
  2. Avoid fleet‑wide cryptographic material. Per‑device keys should be the default for any TLS service.
  3. Store credentials with strong, salted hashes and at‑rest encryption. Unsalted MD5 is trivially crackable.
  4. Ensure factory resets wipe all user data. Devices that retain credentials or location data after a reset create a secondary‑market privacy risk.
  5. Provide reliable OTA rollback mechanisms. Bricking devices during beta testing erodes consumer trust.

9. Conclusion

The TP‑Link Kasa Spot EC71 camera demonstrated how legacy, unauthenticated protocols can persist for years, leaking precise home locations and cryptographic keys. The coordinated‑disclosure effort revealed three critical flaws—unauthenticated GPS exposure, a fleet‑wide RSA private key, and insecure credential storage—and forced TP‑Link to remediate them in firmware 2.4.1. The case highlights the importance of rigorous security reviews, per‑device cryptography, and proper data sanitization before devices enter the secondary market.

Sources