TP-Link Kasa EC71: Fleet-Wide RSA and Unsalted MD5 Exposed in CVE-2026-9770

⏱️ Lectura: 11 min

A researcher physically extracted the firmware from a Kasa Spot EC71 camera using a CH341A programmer and uncovered an IoT security flaw that TP-Link had carried for years: thousands of cameras signed with the same RSA key.

📑 En este artículo

1. TL;DR
2. What it is and why it matters
3. How an IoT firmware audit works
   1. Physical extraction via SPI
4. Practical examples
5. How to start auditing your own IoT device’s firmware
   1. Installing binwalk
6. Real-world case: the Kasa EC71 flaw chain
7. Common mistakes and best practices
8. Comparison: cryptographic and protocol decisions
9. Deeper dive: why the GPS issue took a decade to close
10. Frequently Asked Questions
    1. What is a fleet-wide RSA key and why is it a problem?
    2. Why is unsalted MD5 no longer good enough for storing passwords?
    3. How can I tell if an IoT device exposes data without authentication?
    4. What firmware should I install if I have a Kasa Spot EC71 camera?
    5. What is coordinated vulnerability disclosure?
    6. Why did it take TP-Link six months to close the GPS finding?
11. References

Combined with passwords stored using unsalted MD5 and an unauthenticated exposure of GPS coordinates, the finding resulted in two CVEs published on July 16, 2026, after six months of coordinated disclosure with the manufacturer.

TL;DR

• You’ll understand how IoT firmware is physically extracted with a CH341A programmer over the SPI chip.
• You’ll see why an RSA key shared across thousands of devices is far more serious than a per-unit key.
• You’ll know why unsalted MD5 for passwords is no longer acceptable, not in 2026 and not before.
• You’ll be able to capture unauthenticated UDP traffic from an IoT device with tcpdump or Wireshark.
• You’ll learn the real coordinated disclosure process behind CVE-2026-9770 and CVE-2026-13230.
• You’ll get a table for choosing between MD5, PBKDF2, bcrypt, and Argon2 depending on the case.
• You’ll know which firmware to install today if you own a Kasa EC71 camera (2.4.1).

What it is and why it matters

The Kasa Spot EC71 is a TP-Link indoor camera. An IoT security analysis published by researcher Christopher Childress (BadChemical) on firmware 2.3.26 (build 20240425, release 33797) found three chains of flaws that compromised the device’s confidentiality, integrity, and availability.

The first is an RSA key shared across the entire fleet of devices, registered as CVE-2026-9770. The second, part of the same CVE, is the storage of credentials with unsalted MD5. The third is the unauthenticated exposure of precise GPS coordinates, registered as CVE-2026-13230. TP-Link fixed all three in firmware 2.4.1 after a six-month architectural redesign.

It matters because none of the three flaws is exotic. They’re design mistakes that any team building an IoT product can make, and that a reader can learn to detect in their own hardware using open source tools.

How an IoT firmware audit works

Auditing a closed IoT device almost always starts with the same bottleneck: getting the firmware out of the chip before reading a single line of code. In this case, the researcher didn’t have a downloadable OTA update on hand, so he resorted to physical extraction.

Physical extraction via SPI

Most cheap IoT hardware stores its firmware on an SPI flash memory chip soldered to the board. A programmer like the CH341A, a board that costs less than ten dollars, connects directly to the chip’s pins with a SOIC8 clip and dumps the entire contents to a binary file, bypassing the device’s operating system entirely.

flashrom -p ch341a_spi -r firmware_kasa_ec71_2.3.26.bin

This command tells flashrom to read (-r) the full contents of the chip connected via the CH341A programmer and save it to a local file. The result is a raw binary dump: it’s not readable code yet, it’s the byte-by-byte representation of the flash.

flowchart TD
A["Kasa EC71 camera"] --> B["Physical disassembly"]
B --> C["SOIC8 clip + CH341A programmer"]
C --> D["Binary dump of the SPI chip"]
D --> E["Extraction with binwalk"]
E --> F["Search for credentials and keys"]

With the binary in hand, the next step is identifying what’s inside: bootloader, kernel, filesystem, and, luckily for an attacker, credentials or cryptographic keys embedded in plain text or in poorly protected configurations.

Practical examples

The first analytical step is usually running binwalk on the dump to identify known signatures and automatically extract each section:

$ binwalk -e firmware_kasa_ec71_2.3.26.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes
64            0x40            LZMA compressed data
1245184       0x130000        Squashfs filesystem, little endian, version 4.0

The -e flag tells binwalk to, in addition to identifying signatures, extract each recognized section (kernel, SquashFS filesystem, etc.) to a local folder. From there, you can browse the device’s filesystem as if it were a mounted disk, looking for configuration files, certificates, and service binaries.

A second example, closer to the actual Kasa EC71 flaw, is reproducing in Python the difference between an unsalted hash and a properly derived one:

import hashlib
import os

def hash_md5_sin_sal(password: str) -> str:
    return hashlib.md5(password.encode()).hexdigest()

def hash_pbkdf2_con_sal(password: str, salt: bytes) -> str:
    return hashlib.pbkdf2_hmac("sha256", password.encode(), salt, 200_000).hex()

salt = os.urandom(16)
print(hash_md5_sin_sal("Camara123"))
print(hash_pbkdf2_con_sal("Camara123", salt))

The first function reproduces the Kasa EC71 bug: the same text always produces the same hash, so a precomputed rainbow table reverses it in seconds. The second adds a random salt per credential and 200,000 iterations, which makes precomputing the table infeasible and raises the cost of every brute-force attempt.

How to start auditing your own IoT device’s firmware

You don’t need an expensive hardware lab to replicate the first step of this kind of IoT security audit. Here’s the bare minimum to get started today:

1. Get an SPI programmer: a CH341A costs less than ten dollars and comes with SOIC8 clips so you don’t have to solder.
2. Install binwalk to unpack the dump.
3. Run binwalk on the .bin file to identify the filesystem, bootloader, and embedded strings.
4. Search for credentials and keys with grep over the extracted files: typical paths are /etc/passwd, .pem certificates, and JSON configuration files.

Installing binwalk

On Linux (Debian/Ubuntu):

sudo apt update && sudo apt install binwalk

On macOS (with Homebrew):

brew install binwalk

On Windows, the most stable route is WSL, since binwalk depends on Linux extraction tools:

wsl --install
wsl sudo apt update && sudo apt install binwalk

💡 Tip: run binwalk first with -B (signature identification only) before -e (full extraction): that way you confirm what’s inside without filling your disk with files you might not need.

Real-world case: the Kasa EC71 flaw chain

The initial report was sent to the product security team on January 5, 2026. The vendor confirmed findings 1 (RSA key) and 2 (insecure credentials) on January 27, while closing other minor findings as accepted risk. On March 23, it requested an extension until June for a cross-system architectural redesign, and on that same date the GPS finding was added with its own PoC.

The process wasn’t linear. On May 29, the vendor’s triage response on the GPS finding mentioned an MD5 hash field that existed neither in the reported payload nor in the device’s actual JSON response, evidence that the finding hadn’t been reviewed before responding. The researcher replied with a video PoC documenting that triage failure.

On June 15, a beta firmware 2.4.00 delivered to validate the patch left the test device permanently unresponsive: the LED stayed stuck flashing a pattern of roughly 25 green pulses followed by one red, in a continuous loop, and the vendor confirmed on June 19 that there was no software recovery path. The final firmware, 2.4.1, with all three flaws fixed, was published alongside the advisory on July 16, 2026.

Common mistakes and best practices

The costliest mistake in this story isn’t technical, it’s procedural: TP-Link closed several minor findings as accepted risk without a full architectural review, which let the same class of GPS flaw survive from one product to the next.

⚠️ Heads up: resetting a secondhand IoT device to factory settings doesn’t guarantee that the previous owner’s credentials or GPS coordinates get erased from the manufacturer’s backend.

Another recurring mistake: reusing a single cryptographic key across an entire production line to simplify manufacturing. It’s cheaper to sign once and burn the same key into every unit, but it turns the firmware of a single device bought by anyone into the master key for the entire fleet.

Comparison: cryptographic and protocol decisions

Option	When to use it	Advantage	Limitation
Per-device RSA key	Factory-scale production	Compromising one unit doesn’t affect the rest of the fleet	More complexity in the manufacturing process and key management
Shared RSA key (fleet-wide)	Never recommended	Simpler to manufacture	A single firmware dump compromises the entire fleet, as in the Kasa EC71
Unsalted MD5 hash	Never recommended for credentials	Fast to compute	Vulnerable to precomputed rainbow tables
Salted PBKDF2 / bcrypt / Argon2	Credential storage in 2026	Resists brute force and precomputed tables	Higher CPU cost by design (intentional)

Deeper dive: why the GPS issue took a decade to close

The GPS exposure wasn’t a new finding for the industry. It’s been publicly known since August 2020 in TP-Link’s camera line, and since July 2016 for the underlying unauthenticated protocol that makes it possible. TP-Link had already fixed an identical class of vulnerability in its smart plug line in November 2020, but never extended that fix to the cameras.

That pattern, patching incrementally and piecemeal instead of doing a full architectural review, is the technical explanation for why data as sensitive as a precise GPS location stayed exposed without a login for years in an active product.

sequenceDiagram
participant A as Device on the local network
participant D as Kasa EC71 camera
A->>D: UDP discovery packet without credentials
D-->>A: JSON with precise GPS coordinates
Note over A,D: no authentication is requested at all

The impact of the shared RSA key is best understood as an inverted tree: a single key extracted from a single camera cryptographically compromises every unit sold under that same firmware.

flowchart TD
K["A shared RSA key"] --> D1["EC71 camera unit 1"]
K --> D2["EC71 camera unit 2"]
K --> D3["EC71 camera unit N"]
subgraph Impact
D1
D2
D3
end

The advisory also documents a secondary market vector: resold devices that retain, in the manufacturer’s backend, the previous owner’s credentials and GPS coordinates even after a factory reset.

💭 Key takeaway: a device’s IoT security doesn’t end at its firmware: it includes what the manufacturer’s backend stores about every unit sold.

📖 Summary on Telegram: View summary

Your next step: download the public firmware of an old router you no longer use and run binwalk -e on it to practice extraction before touching a production device.

Frequently Asked Questions

What is a fleet-wide RSA key and why is it a problem?

It’s a single cryptographic key burned into every unit of a model. If it’s extracted from a single legally purchased device, it compromises the entire fleet that shares that key.

Why is unsalted MD5 no longer good enough for storing passwords?

Because it always generates the same hash for the same text, which allows precomputing rainbow tables and reversing it in seconds, without any real brute-force effort.

How can I tell if an IoT device exposes data without authentication?

By capturing its network traffic with tcpdump or Wireshark while the associated app discovers it on the local network, and checking whether the device responds with sensitive data without asking for credentials.

What firmware should I install if I have a Kasa Spot EC71 camera?

Version 2.4.1, which fixes the three flaws described in CVE-2026-9770 and CVE-2026-13230.

What is coordinated vulnerability disclosure?

It’s the process where a researcher privately reports a flaw to the manufacturer and agrees on a deadline for it to be fixed before publishing it, to minimize risk to users.

Why did it take TP-Link six months to close the GPS finding?

Because it required an architectural redesign across several systems, not a simple targeted patch, and that redesign involved deadline extensions, a beta firmware that left a test device unresponsive, and a triage response that hadn’t reviewed the original finding.

References

• BadChemical’s original advisory on GitHub: full report, disclosure timeline, and technical details of the three findings.
• NVD: CVE-2026-9770: official record of the shared RSA key and insecure credential storage.
• NVD: CVE-2026-13230: official record of the unauthenticated GPS coordinate exposure.
• binwalk repository on GitHub: tool used to identify and extract filesystems from a firmware dump.
• python-kasa repository on GitHub: open reference implementation of the Kasa device discovery protocol.

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Denis Nuțiu en Unsplash