TP-Link Kasa Cameras Leaked Home GPS Coordinates for Six Years

Last updated: July 18, 2026

A security researcher's six-month coordinated disclosure with TP-Link has culminated in two CVEs that reveal troubling patterns in consumer IoT security. The most striking finding: Kasa cameras have been leaking precise home GPS coordinates via an unauthenticated UDP endpoint since at least 2020 - and TP-Link only patched it in 2026.

The Core Vulnerability#

A single UDP packet to port 9999 containing {"system":{"get_sysinfo":{}}} returns sub-meter latitude and longitude coordinates, device fingerprints, MAC addresses, and user-assigned device names. No authentication required.

This isn't a novel attack. The TP-Link Smart Home Protocol was publicly documented by softScheck in July 2016. Independent researchers confirmed the GPS leak on KC100 cameras in August 2020. Despite this public knowledge, TP-Link launched a geofencing feature in September 2023 that relies on collecting this exact location data - three years after the vulnerability was documented.

The researcher assessed the CVSS score at 7.1 (High). TP-Link scored it 5.3 (Medium), arguing that location data represents "low confidentiality impact." The researcher disagrees: "Precise home coordinates aren't low confidentiality impact."

What HN Is Saying#

The Hacker News discussion (150+ points, 50+ comments) surfaced the usual IoT security debate, but with some sharp observations:

On the "just use VLANs" crowd: Multiple commenters noted that isolating IoT devices on separate networks doesn't help if the device itself is compromised. One commenter pointed out that Matter-over-Thread and Zigbee alternatives have their own UX nightmares - "horrendously designed from a UX perspective. Easy-to-lose barcodes stuck on cards in the packaging, weird 12-letter codes."

On vibecoders and IoT security: A particularly pointed exchange emerged about AI-generated code in IoT firmware. One commenter reported: "Company with a known name vibecoded a dashboard with Claude. Which also hardcoded a password into the client-side of the dashboard, which I caught." Another noted that TP-Link firmware engineers have left LLM conversation histories publicly indexed by search engines.

On vendor response quality: The researcher's disclosure timeline reveals concerning patterns. TP-Link's May 29 triage response referenced a "MD5 hash in reserved field" that doesn't exist in the actual device behavior - suggesting the finding wasn't technically reviewed before being closed.

The Disclosure Timeline#

The researcher's timeline is a case study in coordinated disclosure challenges:

• January 5, 2026: Initial advisory submitted
• January 27: Vendor confirmed primary findings, closed secondary findings citing CNA Rule 4.1.2
• March 23: Extension requested for "architectural redesign" until early June
• May 29: Triage response referenced non-existent technical details
• June 10: Firmware rollback due to "performance instability at 60% grayscale deployment"
• June 15: Beta firmware permanently bricked the researcher's test device
• June 25: Validated fix in firmware 2.4.1
• July 16: Public advisory

Six months from initial report to patch. The device-bricking beta firmware is particularly troubling - it suggests insufficient QA even on security-critical updates.

The Other CVE: Fleet-Wide Cryptographic Keys#

CVE-2026-9770 (CVSS 8.6) bundles two findings:

Hardcoded RSA keys: Every device running this firmware build shares identical RSA keys - a legacy 1024-bit key from 2014 and an active 2048-bit key from 2021. Both are extractable via a $3-20 SPI flash programmer. Firmware 2.4.1 switches to per-device EC keys provisioned through TP-Link's infrastructure.

Insecure credential storage: User cloud credentials stored as unsalted MD5 hashes with plaintext email addresses. TP-Link ID credentials authenticate across the entire TP-Link ecosystem - Kasa, Tapo, Deco, VIGI - including physical access control devices.

The Secondary Market Risk#

Perhaps the most concerning finding: factory reset doesn't clear previous owner data.

The complete attack chain against secondhand devices:

1. Connect to the device's soft AP during setup
2. Send a UDP packet to retrieve previous owner's GPS coordinates
3. Extract SPI flash to recover plaintext email and MD5 hash
4. Crack the hash via rainbow tables or GPU brute-force
5. Authenticate to TP-Link platforms with recovered credentials
6. Correlate GPS with physical addresses via public databases

This means buying a used Kasa camera exposes the previous owner to credential theft and physical location disclosure - even if they performed a factory reset before selling.

Vendor-Closed Findings#

The researcher documented additional issues that TP-Link closed without remediation:

• Non-rotating cloud tokens that persist across reboots and factory resets
• Authentication bypass via environment variable in production firmware
• Factory-burned root password hashes that violate PSA Certified and NIST SP 800-213 requirements
• Four TLS ports (10443, 17443, 18443, 19443) accepting connections - the EC70 had a CVSS 8.8 stack-based buffer overflow on identical ports in 2023

These remain unpatched in the current firmware.

CCPA Implications#

The researcher notes a policy contradiction: TP-Link's privacy policy restricts precise location collection to users who enable geofencing. However, GPS coordinates are collected at account creation and stored permanently regardless of geofencing status.

This creates potential CCPA compliance issues - collecting data beyond what's disclosed in the privacy policy, and retaining it without the stated justification.

What This Means for IoT Security#

This case illustrates several recurring patterns:

Vulnerability shelf life: A publicly documented vulnerability from 2020 went unpatched until 2026. IoT vendors don't proactively scan for known issues in their protocol implementations.

Disclosure friction: Six months, device bricking, and triage responses that don't match device behavior. Security researchers face significant barriers to getting fixes deployed.

Design-time mistakes: Fleet-wide cryptographic keys and unsalted password hashes aren't bugs - they're architecture decisions that are expensive to fix. The "architectural redesign" extension request suggests TP-Link knew this was deep surgery.

Secondary market externalities: Factory reset not clearing sensitive data creates ongoing risk for users who sell devices. This isn't unique to TP-Link, but it's rarely documented this clearly.

Remediation#

If you're running affected firmware:

1. Update to firmware 2.4.1 or later immediately
2. If you've sold a Kasa camera, consider rotating your TP-Link ID password
3. Consider network isolation for IoT devices (separate VLAN, no internet access if features permit)
4. For new purchases, verify the firmware version before connecting to your network

The full security advisory is available on GitHub with complete technical details.

FAQ#

How did TP-Link Kasa cameras leak GPS coordinates?#

A single unauthenticated UDP packet to port 9999 containing {"system":{"get_sysinfo":{}}} returned sub-meter latitude and longitude, device fingerprints, MAC addresses and user-assigned device names. The GPS leak on KC100 cameras was confirmed by independent researchers in August 2020.

Which firmware fixes the Kasa vulnerabilities?#

The researcher validated the fix in firmware 2.4.1, which also switches from fleet-wide hardcoded RSA keys to per-device EC keys. Several other findings, including non-rotating cloud tokens and four open TLS ports, were closed by TP-Link without remediation and remain unpatched.

Does a factory reset clear previous owner data on a Kasa camera?#

No. Factory reset does not clear previous owner data, so a secondhand device can expose the previous owner's GPS coordinates, plaintext email and unsalted MD5 password hash. If you have sold a Kasa camera, the post suggests considering rotating your TP-Link ID password.

What should Kasa camera owners do now?#

Update to firmware 2.4.1 or later, rotate your TP-Link ID password if you sold a camera, consider isolating IoT devices on a separate VLAN with no internet access where features permit, and check the firmware version on new purchases before connecting them.

Continue Reading#

• Claude Code Is Steganographically Marking Requests
• Codex CLI Hooks for PLC and IoT Firmware Review on the Factory Floor
• EU Forces Google to Open 11 Android Features to Third-Party AI Assistants
• xAI Open-Sources Grok Build After Data Exfiltration Scandal

Sources#

• Full vulnerability disclosure - Complete technical advisory
• Hacker News discussion - 50+ comments on the findings
• softScheck TP-Link Smart Home Protocol analysis (2016) - Original protocol documentation
• CVE-2023-28478 - Prior EC70 buffer overflow on same ports