Legacy D-Link DSL Routers Exploited via Unauthenticated DNS Hijacking (CVE-2026-0625)

LA critical command-injection flaw in legacy (end-of-life) D-Link DSL gateway routers is being actively exploited to achieve unauthenticated remote code execution (RCE) and silent DNS setting changes (DNS hijacking).

What happened (and why it matters)

• The bug is tracked as CVE-2026-0625 (CVSS 9.3) and sits in the router CGI endpoint dnscfg.cgi, where DNS configuration parameters aren’t properly sanitized, enabling command injection.
• Attackers can (a) run arbitrary shell commands and (b) change DNS settings without credentials, letting them redirect traffic for every device behind the router.
• Exploitation attempts were observed (reported by Shadowserver) as early as Nov 27, 2025.

Affected models noted so far

The article lists these impacted legacy models/firmware ranges:

• DSL-2640B ≤ 1.07
• DSL-2740R < 1.17
• DSL-2780B ≤ 1.01.14
• DSL-526B ≤ 2.01

D-Link says identifying all affected models is hard due to firmware variance; they note there’s no reliable model detection beyond firmware inspection and they’re doing a firmware-level review.

Why DNS hijacking is such a nasty outcome

Once DNS is changed at the gateway:

• Users can be transparently redirected to phishing clones (M365, VPN portals, SSO pages).
• Malware downloads can be “legitimized” by redirecting software update domains.
• The compromise becomes persistent until DNS is corrected—affecting every endpoint behind that router.

The Active Directory angle (why AD admins should care)

Active Directory is DNS-dependent.

If a branch office (or home office) uses one of these routers and its DNS gets hijacked:

• Domain-joined endpoints may stop locating DCs (SRV lookups fail), breaking logons, GPO processing, SMB access, certificate enrollment, and “normal Windows” behavior.
• More dangerously: users may be redirected to credential-harvest pages that look like Entra ID / ADFS / VPN / Outlook Web, leading to stolen AD creds and lateral movement.
• Even if Kerberos prevents “fake DC” tricks in many cases, phishing + MFA fatigue + token theft is the practical route attackers use once traffic is steered.

“Is there any way to avoid this with a PowerShell hack or AD hack?”

Not in the way you mean.

• You can’t reliably “PowerShell/AD” your way out of a router RCE + DNS-change vulnerability. The fix is: retire/replace the router (especially if it’s EoL and unpatchable). That’s also D-Link’s guidance for these legacy gateways.
• What you can do is reduce the blast radius using AD/GPO controls + endpoint enforcement + monitoring, so even if a gateway’s DNS gets changed, your domain devices don’t blindly follow it.

Practical defenses AD teams can deploy (realistic and effective)

1) Force domain clients to use your AD DNS (and only your AD DNS)

Best path: DHCP hands out only your internal DNS resolvers (Option 006), and clients are prevented from using random resolvers.

If you have devices that end up with rogue DNS anyway (Wi-Fi, travel, bad DHCP), enforce outbound DNS control:

2) Block outbound DNS to the internet from endpoints (except your resolvers)

Via Windows Firewall GPO:

• Block UDP/TCP 53 to “Any”
• Allow UDP/TCP 53 only to your internal DNS IPs (DCs / DNS servers)

This prevents a hijacked router from pushing clients to use attacker-controlled resolvers.

3) Monitor DNS server settings on domain machines (PowerShell audit)

Run this from an admin box (with appropriate remoting rights) to flag machines using non-approved DNS resolvers:

$Approved = @("10.0.0.10","10.0.0.11")  # your DC/DNS IPs

$Computers = Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=example,DC=com" |
            Select-Object -ExpandProperty Name

$Results = foreach ($c in $Computers) {
  try {
    $dns = Invoke-Command -ComputerName $c -ScriptBlock {
      Get-DnsClientServerAddress -AddressFamily IPv4 |
        Select-Object -ExpandProperty ServerAddresses
    } -ErrorAction Stop

    $bad = $dns | Where-Object { $_ -and ($_ -notin $using:Approved) }
    [pscustomobject]@{
      Computer = $c
      DnsServers = ($dns -join ", ")
      NonApproved = ($bad -join ", ")
      Status = if ($bad) { "NON-COMPLIANT" } else { "OK" }
    }
  } catch {
    [pscustomobject]@{
      Computer = $c
      DnsServers = ""
      NonApproved = ""
      Status = "UNREACHABLE/ERROR"
    }
  }
}

$Results | Sort-Object Status, Computer | Format-Table -AutoSize

4) Quick endpoint containment if you suspect DNS hijack

On impacted machines:

• Reset DNS servers to your known-good resolvers
• Flush cache

# Example: set on a specific adapter
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses @("10.0.0.10","10.0.0.11")

Clear-DnsClientCache
ipconfig /flushdns | Out-Null

5) Watch your AD DNS servers for “sudden forwarding changes”

This attack targets routers, not AD DNS—BUT attackers often chain DNS abuse. On DNS servers/DCs, periodically verify forwarders/root hints/conditional forwarders:

Get-DnsServerForwarder
Get-DnsServerRootHint
Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated

If you want change visibility, pair this with:

• Scheduled exports + diff
• Config auditing / privileged access hardening for DNS admins

What to do if you have these D-Link devices in the wild

Because the affected DSL gateways are legacy/EoL, the practical guidance is:

1. Replace/retire any affected devices (especially anything internet-exposed).
2. If replacement isn’t immediate: isolate them (no WAN admin), restrict management to a management VLAN, and treat them as “compromised-by-design” until removed.
3. Assume endpoints behind them may have experienced traffic interception/credential phishing; rotate passwords/tokens appropriately for affected users.