logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·04.11.26
← Back to news

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

Original article
github.com|194 points|78 comments|by BadChemical|Jul 17, 2026

Security Advisory: TP-Link Kasa Spot EC71

Researcher: Christopher Childress (BadChemical)
Status: Remediated\text{Remediated}Remediated (Patched in version 2.4.1)
Identifiers: CVE-2026-9770 (RSA/IAM) & CVE-2026-13230 (GPS)


[!IMPORTANT] Legal Disclaimer: This documentation provides a proof of concept for vulnerabilities that have already been patched in the TP-Link Kasa Spot EC71. This content is intended solely for defensive research and educational purposes.

📌 Executive Summary

A deep-dive security audit of the Kasa Spot EC71 indoor camera uncovered several critical flaws that threatened the device's integrity, availability, and confidentiality.

Methodology

The researcher employed a multi-pronged attack vector to uncover these flaws:

  1. Physical Extraction: Using a CH341A programmer to read the SPI flash chip directly.
  2. Network Analysis: Active monitoring and analysis of network packets.
  3. Hardware Analysis: Direct inspection of the device circuitry.

Core Vulnerabilities

The analysis identified three primary failure points:

  • Cryptographic Collapse: The use of a fleet-wide RSA key.
  • Weak Storage: Credentials stored using unsalted MD5 hashes.
  • Privacy Leak: Precise GPS coordinates exposed via unauthenticated UDP.

Remediation Status

  • Fleet-wide RSA key replaced
  • MD5 credential storage updated
  • Unauthenticated GPS exposure closed
  • Comprehensive architectural review (indicated as lacking by researcher)

🔍 Technical Deep Dive

The GPS Leak & Vendor Negligence

The most striking finding was the exposure of home GPS coordinates. This wasn't a new bug; the underlying protocol had been unauthenticated since July 2016, and the vulnerability was known across TP-Link's camera line since August 2020.

Interestingly, TP-Link fixed this exact issue in their smart plug line in November 2020 but forgot failed to apply the same fix to their cameras. This suggests a pattern of incremental patching rather than a holistic security overhaul.

Cryptographic Failures

The device relied on insecure hashing for credentials. The mathematical representation of this failure can be viewed as: Password→MD5Hash (No Salt)\text{Password} \xrightarrow{\text{MD5}} \text{Hash (No Salt)}PasswordMD5​Hash (No Salt) Because there was no salt, these hashes are trivial to crack using rainbow tables.

Secondary Market Risk

A significant "hidden" risk exists for second-hand buyers or sellers. Because factory resets do not properly purge all data, a new owner could potentially recover the previous owner's GPS coordinates and credentials.

Attack Flow Visualization


📅 Coordinated Disclosure Timeline

The process of reporting and fixing these bugs spanned six months and was marked by several triage failures.

DateEventOutcome/Detail
Jan 05, 2026Initial ReportAdvisory sent to TP-Link security team.
Jan 14, 2026AcknowledgmentVendor confirmed firmware v2.3.26.
Jan 16, 2026PoC RequestVendor committed to fixing TLS certificates.
Jan 27, 2026Partial ConfirmationRSA and Credential findings confirmed; others closed as "accepted risk."
Mar 23, 2026ExtensionVendor requested more time for architectural redesign.
Mar 24, 2026GPS SubmissionNew GPS finding submitted (Ticket TPVD20260324001).
May 29, 2026Triage FailureVendor responded referencing an MD5 hash that didn't exist in the payload.
May 29, 2026RebuttalResearcher submitted a video PoC proving the triage failure.
Jun 10, 2026RollbackCVE-2026-9770 delayed due to grayscale deployment instability.
Jun 15, 2026The BrickBeta firmware 2.4.00 rendered the test device dead.
Jun 21, 2026ResolutionVendor provided a replacement device.

⚠️ The "Bricking" Incident

During the validation of beta firmware 2.4.00, the test device became permanently unresponsive. The hardware entered a boot-loop characterized by a specific LED sequence:

// LED Error Pattern Observed:
while(true) {
    for(int i=0; i<25; i++) {
        set_led(GREEN); 
        pulse();
    }
    set_led(RED);
    pulse();
}

Following an engineering review, TP-Link confirmed there was no software-based recovery path for this state, necessitating a full hardware replacement.

Final Device Specifications

  • Vulnerable Build: 20240425 (Release ID: 33797)
  • Patched Version: 2.4.1
  • Hardware Interface: SPI Flash →\rightarrow→ CH341A