CVE-2021-40407

What it actually does

This vulnerability is an unauthenticated network-reachable OS command injection flaw in the Reolink RLC-410W IP camera firmware, specifically in DDNS network settings handling. The SetDdns API accepts a domain parameter that is assigned to the DDNS domain value without proper validation or shell-safe handling. When the firmware later builds an operating-system command using that value, attacker-controlled shell metacharacters can be interpreted by the device OS. Successful exploitation can allow arbitrary command execution with the privileges of the vulnerable camera service, enabling full compromise of device confidentiality, integrity, and availability.

Why it matters to the business

An exposed vulnerable camera can be remotely taken over without user interaction, allowing attackers to view or disrupt camera operations, alter configuration, pivot into adjacent network segments, deploy botnet or malware tooling, or use the device as a foothold for broader attacks. Because this vulnerability is listed in CISA KEV with active exploitation in the wild and a remediation due date of 2025-01-08, internet-facing instances should be treated as high-priority remediation targets. Even though it is not currently flagged as used in ransomware campaigns, compromised cameras are commonly abused for persistence, reconnaissance, proxying, and botnet activity.

How an attack unfolds

An attacker first identifies a reachable Reolink RLC-410W camera running affected firmware. They then send a crafted HTTP request to the device's SetDdns API, placing shell metacharacters and commands into the domain parameter used by DDNS configuration logic. Because the firmware does not properly validate or safely quote that value, the injected content is passed into an OS command context. The device executes the attacker-supplied command, which may be used to download malware, start a reverse shell, change camera configuration, create persistence, disable services, or use the camera as a relay for additional scanning and attacks. In observed real-world exploitation patterns for embedded device command injection, follow-on activity often includes use of busybox utilities, wget/curl/tftp downloads, execution from temporary directories, process hiding, and outbound connections to attacker-controlled infrastructure.

How to fix it

Upgrade affected Reolink RLC-410W firmware to a vendor-provided fixed release if available from Reolink support or the official firmware download channel. No fixed version was provided in the supplied advisory data, so organizations should verify the latest firmware directly with the vendor and prioritize replacement or isolation where no supported fix exists. Remove direct internet exposure for camera management interfaces, place cameras on isolated network segments, restrict access to trusted management hosts via firewall or ACLs, and disable DDNS functionality if it is not required. Change camera credentials after remediation because command execution may have exposed configuration data or enabled persistence. For devices that cannot be updated, apply compensating controls: block inbound access from untrusted networks, block egress except to required destinations, monitor for suspicious outbound connections, and consider device replacement.

How to confirm the fix worked

Confirm every Reolink RLC-410W device is inventoried and running a vendor-supported firmware version that is not vulnerable. Validate that the camera management/API interface is not reachable from the public internet and is only accessible from approved management networks. Test firewall rules by attempting to reach the web/API service from untrusted network locations. Review configuration to ensure DDNS is disabled unless explicitly required. Where safe and authorized, use vulnerability scanning or a non-destructive check that verifies firmware version and exposure of the SetDdns API; avoid sending exploit payloads that execute commands on production devices. After patching or isolation, confirm that crafted requests containing shell metacharacters in DDNS domain fields are rejected, sanitized, or not executed.

Typical attack path

1. Scan the internet or internal address ranges for exposed Reolink RLC-410W cameras or recognizable Reolink web/API services.
2. Fingerprint the firmware or test for the vulnerable SetDdns API behavior.
3. Send a crafted HTTP request to the SetDdns API with command separators or shell substitution syntax embedded in the domain parameter.
4. Cause the camera firmware to pass the malicious DDNS domain value into an operating-system command.
5. Execute attacker-controlled commands on the device.
6. Download and run additional tooling such as a botnet payload, reverse shell, scanner, or persistence script.
7. Use the compromised camera to spy, disrupt service, proxy traffic, scan adjacent networks, or participate in broader campaigns.

How to detect it

Review camera web/API access logs, reverse proxy logs, firewall logs, IDS/IPS telemetry, and packet captures for requests to the SetDdns API, especially requests where the domain parameter contains shell metacharacters such as semicolons, pipes, backticks, dollar-parentheses, redirection operators, or encoded equivalents. Correlate suspicious SetDdns requests with immediate outbound traffic from the camera to unfamiliar IPs or domains, especially HTTP, HTTPS, TFTP, FTP, Telnet, SSH, IRC, or high-numbered ports. On devices or forensic images where shell/process visibility is available, look for web service child processes spawning /bin/sh, busybox, wget, curl, tftp, nc, telnetd, chmod, or scripts under temporary directories. Review DNS logs for camera-originated lookups to newly registered or unusual domains shortly after DDNS configuration changes. Inspect configuration for unexpected DDNS settings, modified DNS servers, new users, altered credentials, disabled logging, unexplained reboots, or changed network settings. Network-based detections should alert on HTTP requests containing SetDdns combined with command-injection characters or encoded command payloads. Because active exploitation has been reported, absence of logs on the device should not be treated as proof of no compromise; use network telemetry and egress monitoring as primary evidence sources.

• cmd=SetDdns
• SetDdns
• /cgi-bin/api.cgi?cmd=SetDdns
• domain=
• domain=%3B
• domain=;
• domain=%7C
• domain=|
• domain=%60
• domain=`
• domain=%24%28
• domain=$(
• ;wget
• ;curl
• |wget
• |curl
• busybox wget
• busybox tftp
• /bin/sh
• /tmp/
• /var/tmp/
• chmod +x
• telnetd
• nc -e
• /dev/tcp/

What your security team should do

• Immediately identify all Reolink RLC-410W cameras and determine firmware versions and network exposure.
• Prioritize remediation for any device reachable from the internet or untrusted network zones, due to active exploitation and CISA KEV listing.
• Upgrade to the latest vendor firmware where available; if no fixed firmware is available, isolate or replace the device.
• Block external access to camera web/API management interfaces and restrict administrative access to trusted management networks only.
• Disable DDNS on affected cameras unless there is a documented business requirement.
• Rotate device credentials and review configuration after remediation because exploitation may have exposed secrets or modified settings.
• Hunt historical web/API logs, firewall logs, DNS logs, and outbound network telemetry for SetDdns requests followed by suspicious command execution or outbound downloads.
• Monitor cameras for unexpected outbound connections, new listening services, unusual reboots, high CPU/network use, or files/processes launched from temporary directories.
• Apply egress filtering so cameras can only communicate with required NTP, DNS, management, update, and video destinations.
• If compromise is suspected, remove the device from the network, preserve logs/configuration where possible, reflash firmware or factory reset, rotate credentials, and redeploy only behind segmentation controls.