CVE-2026-0918: Tapo Camera DoS Vulnerability

CVE-2026-0918 Overview

CVE-2026-0918 is a Null Pointer Dereference vulnerability affecting TP-Link Tapo C220 v1 and C520WS v2 security cameras. The HTTP service on these devices does not safely handle POST requests containing an excessively large Content-Length header. When such a request is received, the resulting failed memory allocation triggers a NULL pointer dereference, causing the main service process to crash. An unauthenticated attacker on the adjacent network can repeatedly crash the service, causing temporary denial of service. The device restarts automatically, but repeated requests can keep it unavailable for extended periods.

Critical Impact
Unauthenticated attackers on the local network can persistently disable TP-Link Tapo security cameras, creating surveillance blind spots and potentially enabling physical security breaches.

Affected Products

TP-Link Tapo C220 v1 Security Camera
TP-Link Tapo C520WS v2 Security Camera

Discovery Timeline

2026-01-27 - CVE-2026-0918 published to NVD
2026-01-29 - Last updated in NVD database

Technical Details for CVE-2026-0918

Vulnerability Analysis

This vulnerability is classified as CWE-476 (NULL Pointer Dereference). The affected TP-Link Tapo cameras expose an HTTP service that processes incoming POST requests. When a malformed POST request contains an excessively large Content-Length header value, the service attempts to allocate memory based on this declared size. When the memory allocation fails due to insufficient available memory, the service does not properly handle the failure condition.

Instead of gracefully rejecting the request or returning an appropriate error response, the service proceeds to dereference the NULL pointer returned by the failed allocation. This causes the main service process to crash immediately. Because the attack requires only network adjacency and no authentication, any device on the same local network segment can exploit this vulnerability.

Root Cause

The root cause of this vulnerability lies in improper error handling within the HTTP service's request processing logic. When the service receives a POST request, it reads the Content-Length header and attempts to allocate a memory buffer of that size. The code fails to validate whether the requested size is reasonable before attempting allocation, and critically, does not check if the memory allocation succeeded before using the returned pointer. This missing NULL check after malloc() or equivalent memory allocation function leads directly to the NULL pointer dereference crash.

Attack Vector

The attack is exploitable from an adjacent network position, meaning the attacker must be on the same local network segment as the vulnerable camera. No authentication is required to trigger the vulnerability. An attacker crafts a POST request with an artificially large Content-Length header value—one that exceeds available memory on the embedded device.

When the camera's HTTP service receives this request, it attempts to allocate a buffer matching the declared Content-Length. The allocation fails due to insufficient memory, returning NULL. The service then attempts to write incoming request data to this NULL pointer, causing an immediate crash. Since the camera automatically restarts after a crash, an attacker can script repeated malicious requests to maintain a persistent denial of service condition.

Detection Methods for CVE-2026-0918

Indicators of Compromise

Repeated camera service restarts visible in device logs
Network traffic showing POST requests with abnormally large Content-Length headers (values exceeding available device memory)
Camera feeds becoming intermittently unavailable despite stable network connectivity
Increased reboot cycles detected on affected Tapo camera devices

Detection Strategies

Monitor network traffic for HTTP POST requests to camera IP addresses with Content-Length headers exceeding reasonable thresholds (e.g., values greater than 100MB)
Implement network intrusion detection rules to flag anomalous Content-Length values targeting IoT device subnets
Configure alerting on camera availability to detect persistent unavailability patterns
Review DHCP logs for unusual frequency of IP address requests from camera MAC addresses indicating repeated reboots

Monitoring Recommendations

Deploy network segmentation to isolate IoT cameras on dedicated VLANs with traffic inspection
Implement network behavior analysis to baseline normal camera traffic patterns and alert on deviations
Enable logging on network firewalls to capture all traffic to and from camera devices
Consider implementing rate limiting on HTTP requests to camera devices at the network level

How to Mitigate CVE-2026-0918

Immediate Actions Required

Update affected TP-Link Tapo C220 v1 cameras to the latest available firmware
Update affected TP-Link Tapo C520WS v2 cameras to the latest available firmware
Isolate vulnerable cameras on a separate network segment with restricted access
Implement network access controls to limit which devices can communicate with cameras

Patch Information

TP-Link has made firmware updates available for the affected camera models. Users should download and apply the latest firmware from the official TP-Link support pages:

TP-Link Tapo C220 Firmware - Download the latest firmware for C220 v1
TP-Link Tapo C520WS Firmware - Download the latest firmware for C520WS v2

For additional guidance, consult the TP-Link Tapo C220 FAQ.

Workarounds

Place affected cameras behind a firewall that filters HTTP traffic and blocks requests with excessively large Content-Length headers
Implement network segmentation to restrict camera access to trusted management hosts only
Disable direct HTTP access to cameras if cloud-based management is sufficient for operational needs
Deploy intrusion prevention systems (IPS) with signatures to detect and block exploitation attempts

bash

# Example: iptables rule to isolate camera subnet (adjust IPs as needed)
# Allow only management host to communicate with camera
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -j DROP
iptables -A FORWARD -s 192.168.1.100 -d 192.168.20.0/24 -j ACCEPT