TP-Link Kasa Spot EC71 (Firmware 2.3.26) GPS Leak, Hardcoded RSA Keys, and MD5 Credential Issues – Full Disclosure and Impact

TP-Link Kasa Spot EC71 (Firmware 2.3.26) GPS Leak, Hardcoded RSA Keys, and MD5 Credential Issues – Full Disclosure and Impact

TP‑Link Kasa Spot EC71 indoor camera leaked precise home GPS via an unauthenticated UDP request for six years, and also shipped fleet‑wide RSA private keys and unsalted MD5 credential hashes.

The vulnerabilities were disclosed in January 2026, patched in firmware 2.4.1 (July 2026), and sparked a coordinated‑disclosure saga that included a bricked test device, a faulty triage response, and a secondary‑market attack path that exposed previous owners’ home locations and global TP‑Link credentials.

Key Findings at a Glance

Finding CVE Core Issue Impact
1 CVE‑2026‑9770 Hard‑coded fleet‑wide RSA private key (2048‑bit) stored in SPI flash Any attacker who extracts the key from a single device can decrypt TLS traffic for the entire EC71 fleet.
2 CVE‑2026‑9770 (same ID) User TP‑Link ID email stored in plaintext and password stored as an unsalted MD5 hash Trivial cracking yields global credentials that work across all TP‑Link cloud services (Kasa, Tapo, Deco, VIGI, etc.).
3 CVE‑2026‑13230 Unauthenticated UDP get_sysinfo response on port 9999 reveals precise GPS coordinates, hardware IDs, and firmware version Anyone on the local network can obtain the owner’s exact home location and a unique device fingerprint without any authentication.

"A single UDP packet returns sub‑meter home coordinates with no authentication required. TP‑Link scored it 5.3 medium; my independent assessment is 7.1 high." – Christopher Childress (BadChemical), original disclosure comment.

Finding 1 – Fleet‑wide RSA Private Keys

Answer‑first: The EC71 firmware contains two RSA key/certificate pairs, one 1024‑bit (expired) and one active 2048‑bit, both embedded in the read‑only SquashFS filesystem and identical across every device running firmware 2.3.26.

  • The active 2048‑bit key is signed with SHA‑256, valid until July 2031, and is served by the device at runtime.
  • Both private keys can be extracted directly from the SPI flash using a cheap CH341A programmer.
  • Because the key is fleet‑wide, compromising a single camera gives an attacker the cryptographic material to impersonate any EC71 unit in the field.
  • The vendor initially described the issue as “issues related to the local communication TLS certificates” in its January 16 2026 response, downplaying the broader cryptographic exposure.

Finding 2 – Unsalted MD5 Credential Storage & Cross‑Domain Compromise

Answer‑first: User TP‑Link ID credentials are stored in config/account as a plaintext email address and an unsalted MD5 hash of the password, persisted across factory resets.

  • The MD5 hash can be cracked instantly with publicly available rainbow tables or a modest GPU rig.
  • TP‑Link ID is a single sign‑on credential used across the entire TP‑Link ecosystem (Kasa, Tapo, Deco, VIGI, Omada, etc.).
  • Recovering the hash therefore enables global account takeover, allowing an attacker to control smart locks, mesh routers, and commercial surveillance equipment.

"The credential finding (CVE‑2026‑9770) covers a fleet‑wide RSA key and unsalted MD5 TP‑Link ID credentials. Same credentials provide global authentication across the TP‑Link ecosystem." – BadChemical

Finding 3 – Unauthenticated Precise GPS Exposure (CVE‑2026‑13230)

Answer‑first: Sending the JSON payload {"system":{"get_sysinfo":{}}} to UDP port 9999 elicits a clear‑text response that includes the device’s exact latitude/longitude, hardware identifiers (oemId, hwId, deviceId, mac, mic_mac), user‑assigned alias, and full firmware version.

  • The response is only XOR‑obfuscated; Wireshark decodes it automatically.
  • GPS coordinates are captured from the mobile device during account creation and stored permanently in config/location. They never rotate unless the user manually syncs.
  • The same unauthenticated protocol has been publicly documented since July 2016 (softScheck’s HS110 reverse‑engineering) and the GPS leak was first reported on a TP‑Link KC100 camera in August 2020.
  • TP‑Link’s own geofencing feature, introduced in September 2023, relies on the mobile device’s location, not the camera‑stored coordinates, making the firmware’s collection of precise GPS data an undocumented, opt‑in‑required practice.

"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." – BadChemical

Historical Context and Scope

  • The unauthenticated Smart Home Protocol on port 9999 has been known to allow arbitrary control of TP‑Link plugs since 2016 (softScheck).
  • The GPS exposure was observed on the KC100 camera in 2020 and re‑appeared unchanged on the EC71 firmware built in April 2024.
  • TP‑Link previously remediated the same GPS issue on its smart‑plug line in November 2020, but failed to apply the fix to the camera line until 2026.
  • Independent research (Mandiant, 2023) disclosed a stack‑based buffer overflow on the same local service ports for the EC70/EC71 family (CVE‑2023‑28478, CVSS 8.8).

Coordinated Disclosure Timeline (Key Milestones)

Date Milestone
Jan 5 2026 Initial advisory sent to TP‑Link product security team.
Jan 16 2026 Vendor acknowledges report, asks for PoC, promises TLS‑certificate remediation.
Mar 23 2026 Vendor requests extension to early June for architectural redesign; GPS finding submitted.
Jun 5 2026 Vendor asks for open‑ended extension on GPS deadline; extension denied.
Jun 15 2026 Beta 2.4.00 OTA bricks test device; factory reset becomes non‑functional.
Jun 24 2026 Beta 2.4.1 delivered to replacement device; validation confirms remediation of all three findings.
Jul 14 2026 Public advisory and CVE issuance (CVE‑2026‑9770, CVE‑2026‑13230).

"The disclosure timeline is brutal…" – BobbyTables2 (HN comment).

Real‑World Impact

Privacy Violation

  • Precise GPS coordinates (sub‑meter accuracy) constitute personal data under CCPA and GDPR. The vendor’s own privacy policy only permits precise location collection when the user explicitly enables geofencing, which the EC71 does not require.
  • An attacker can correlate the leaked coordinates with public property records to infer the occupant’s identity, interior layout, or even target physical burglary.

Cross‑Domain Account Takeover

  • The unsalted MD5 password hash enables rapid cracking, granting the attacker access to every TP‑Link cloud service tied to the same TP‑Link ID (smart locks, mesh Wi‑Fi, surveillance, etc.).
  • Combined with the GPS fingerprint, an attacker can pinpoint which account belongs to which physical address.

Secondary‑Market Threat

  • Devices returned to factory settings retain the previous owner’s email (plaintext) and MD5 password hash in the config/account overlay.
  • The soft‑AP mode during setup still answers the unauthenticated get_sysinfo request, leaking the former owner’s GPS coordinates.
  • Attack chain (no network access to the victim’s LAN required):
    1. Power on second‑hand EC71 and connect to its soft‑AP.
    2. Send UDP get_sysinfo request → obtain GPS.
    3. Extract SPI flash → recover email & MD5 hash.
    4. Crack hash → obtain global TP‑Link credentials.
    5. Log into any TP‑Link service and control devices.

"The combination of findings creates a compounded risk for devices that are resold, donated, or otherwise transferred to new owners." – BadChemical

Vendor Response, Patch Details, and New Issues

Answer‑first: TP‑Link released firmware 2.4.1, which removes the fleet‑wide RSA private key, encrypts credential storage, and eliminates the GPS data from the unauthenticated UDP response.

  • RSA remediation: The legacy uhttpd.key and uhttpd.crt files were deleted; per‑device certificates are now provisioned via a NOC infrastructure. mbedTLS upgraded from 2.6.0 to 2.28.1.
  • Credential storage: An at‑rest AES encryption routine (check_default_config) now protects the config/account file, preventing plaintext email and MD5 hash exposure.
  • GPS fix: Port 9999 no longer replies to unauthenticated get_sysinfo; the Kasa app now uses an authenticated UDP discovery broadcast that includes only a public RSA key.

Beta Firmware Problems

  • Beta 2.4.00 (June 11‑15 2026) caused a permanent brick: the device entered a non‑recoverable LED pattern (≈25 green pulses + 1 red pulse) and factory reset failed. Recovery required a hardware SPI reflash.
  • Beta 2.4.1 succeeded in fixing the security issues but retained a static root password hash in /etc/shadow (see Finding 5), which the vendor claims is unused—a claim contradicted by pre‑init scripts that evaluate the $FAILSAFE variable.

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

Independent CVSS Assessment vs. Vendor Score

  • TP‑Link assigned CVSS 4.0 5.3 Medium (VC:L) to CVE‑2026‑13230.
  • The researcher’s independent assessment rates it CVSS 4.0 7.1 High (VC:H), arguing that precise home coordinates are high‑confidentiality data under CCPA and that the exposure occurs without any authentication.
  • The discrepancy highlights a broader industry issue: vendors often under‑score privacy‑impacting bugs that lack direct system compromise.

Triage Missteps and Communication Gaps

Answer‑first: The vendor’s May 29 2026 triage response mistakenly referenced an MD5 field that does not exist in the get_sysinfo JSON payload, effectively misclassifying the GPS leak.

  • The tracking number TPVD20260324001 shows the finding was logged correctly, but the response described a different vulnerability entirely.
  • A rebuttal video demonstrating the PoC was submitted the same day, yet the vendor did not update its assessment.

"Why do people keep buying all this garbage and putting it in their homes?" – AndyMcConachie (HN comment, reflecting community frustration).

Lessons for IoT Security Practitioners

  1. Never trust unauthenticated local protocols – Even seemingly innocuous discovery endpoints can leak high‑value PII.
  2. Encrypt all persistent data, especially credentials and location information, and ensure factory resets wipe them.
  3. Avoid fleet‑wide cryptographic material – Unique per‑device keys prevent a single compromise from cascading.
  4. Coordinate disclosure timelines with realistic remediation windows; six‑month negotiations can leave users exposed for years.
  5. Test OTA updates thoroughly – A bricked device erodes trust and may force costly hardware replacements.
  6. Publish accurate CVSS metrics that reflect privacy impact, not just confidentiality/confidentiality of the device.

Community Reactions (Selected Hacker News Comments)

"This underscores the principle that IoT devices should not be allowed to communicate over the public Internet. Pretty much all cheap, Chinese‑made hardware of this kind has intentional or unintentional security holes waiting to be exploited." – drnick1

"The report seems obviously AI generated, so I can’t be bothered to read in its entirety, but based on my quick skim, ‘leaked home GPS’ makes it sound worse than it is. Unless you’re dumb enough to set DMZ on this device, this won’t be exposed to the internet, and if it’s LAN only, don’t you already know the location?" – gruez

"A shocking number of devices are continuously reporting location data over random unencrypted protocols. What’s worse, they’re often sending the data to cloud IPs that aren’t even controlled by the company, so some random person is getting your real‑time location." – ericpauley

References

This article synthesizes the security advisory, coordinated‑disclosure timeline, and community commentary surrounding the TP‑Link Kasa Spot EC71 vulnerabilities. All technical details are drawn directly from the disclosed documents and public comments; no speculative information has been added.

Sources