Smart Home Security Research — CVE-2026–0918 Assigned
- Azim Javed
- Feb 11
- 2 min read
Updated: 4 days ago
From having online meetings to getting real CVEs, the CRAC Learning team did it all!
We discovered a Denial-of-Service vulnerability in the HTTP service of the TP-Link Tapo C100 v5 IP camera. Sending a POST request with an excessively large Content-Length header causes the main HTTP process to crash, freezing video and audio streams and forcing a restart. TP-Link acknowledged and published a fix; the issue was assigned CVE-2026–0918 and a High score (CVSS v4.0 7.1).
Tapo cameras are widely deployed worldwide, making them an obvious choice for security experimentation due to the potential impact on a large user base.
We referred Pre-Auth HTTPS Content-Length Integer Overflow (CVE-2025–14299) details to understand the existing flaw in the HTTPS server routine running on port 443 has a classic integer overflow in its Content-Length header parsing. On systems where integers have a fixed width (such as 32-bit architectures), providing a numeric string that exceeds the maximum representable value of a signed integer results in an integer overflow. This leads to undefined behavior, typically manifesting as a memory corruption or a denial-of-service (DoS) condition, causing the application process to terminate unexpectedly.
The camera’s HTTP handler trusts the Content-Length header and attempts to allocate or prepare for that many bytes of memory without sufficient sanity checks. When a very large value is supplied, memory allocation fails and the code subsequently dereferences a NULL pointer (CWE-476), which crashes the service process. The crash takes down the camera’s live video and audio pipelines. Although the device reboots, repeated requests can keep it unavailable (resource exhaustion → persistent DoS). This is confirmed by the NVD and TP-Link records.
On our lab device shown above (the Tapo C100 v5, firmware 1.3.5, Hardware 5.80) we used the Tapo app to discover the local IP address and then sent a crafted POST request with an excessively large Content-Length value. The camera froze within seconds and the live stream dropped. First let’s do a basic nmap on the device.
Exploit
See the below PoC screenshot for the complete command.
Why is this exploitable?
Attacker Network: Same LAN (no authentication is required).
Attack Complexity: low
Impact: High on availability (video/audio stoppage).
NVD and TP-Link list the weakness as a NULL pointer dereference and rate the issue as “High”.
How can this be fixed?
1. Parse Content-Length with strict bounds (use strtoull/strtoul with range checks) and reject values above an implementation cap.
2. Always check allocation results before dereferencing; fail safely (return 413 / close connection).
3. Implement per-connection request size caps and read timeouts (don’t wait forever for bytes that are never going to come).
4. Reject requests with excessively large values and mismatched payload sizes.
We reported this bug on 16/01/2026; TP-Link acknowledged and released fixes. CVE record (CVE-2026–0918) now references the issue (CWE-476). Thanks to the TP-Link team for coordinated response and credit.
More about the vulnerability can be read here — “https://www.cve.org/cverecord?id=CVE-2026-0918"
Comments