CVE-2026-0625: Injeção de comando não autenticado de realidade não corrigível em gateways DSL legados da D-Link

Por que esse CVE é importante além do título do CVSS

O CVE-2026-0625 é um Injeção de comando do sistema operacional (mapeado para CWE-78) que afeta vários gateway DSL antigo da D-Link dispositivos. A superfície vulnerável é a pilha de gerenciamento da Web incorporada do dispositivo, especificamente o dnscfg.cgi usado para a configuração do DNS. Como os parâmetros de DNS não são devidamente higienizados, um invasor não autenticado pode injetar metacaracteres de shell e obter execução remota de código (RCE). O CNA (VulnCheck) atribuiu um CVSS 9.3 (crítico) pontuação. (NVD)

Mas o impacto operacional não é apenas um "RCE crítico". A verdadeira história é gravidade do ciclo de vida: esses dispositivos estão em fim de vida útil/fim de suporte, e a orientação pública converge consistentemente para aposentar e substituir em vez de aplicar patches. Em outras palavras, os defensores são forçados a usar controles de compensação - redução da exposição da rede, segmentação e monitoramento da integridade do DNS - porque a correção do firmware geralmente está fora de cogitação. (supportannouncement.us.dlink.com)

O que foi afetado (confirmado) e o que permanece incerto

Os relatórios públicos fornecem um conjunto concreto e confirmado de modelos e intervalos de firmware afetados. O VulnCheck e a cobertura downstream listam o seguinte (observe os intervalos de desigualdade):

A nuance importante: A D-Link afirma que há nenhuma maneira confiável de determinar os modelos afetados apenas pelo número do modeloA verificação pode exigir que a biblioteca CGI vulnerável varie entre as compilações de firmware. inspeção direta de firmware. (supportannouncement.us.dlink.com)

Essa é uma armadilha clássica no gerenciamento de vulnerabilidades de dispositivos de borda: os rótulos de inventário nem sempre são mapeados de forma clara para a linhagem do software. Se você opera operadoras, filiais ou gateways de "TI invisível", presuma que sua exposição é mais ampla do que a tabela de quatro linhas até que se prove o contrário.

Contexto de exploração: como os atacantes chegam dnscfg.cgi em ambientes reais

A frase de alta taxa de cliques dominante nos títulos mais bem classificados é essencialmente uma composição: "roteadores de dia zero explorados ativamente / RCE crítico / roteadores em fim de vida útil". Você verá o mesmo gancho repetido nos principais veículos de segurança porque ele comprime três sinais de urgência em uma linha: a exploração está acontecendo agora, o impacto é a execução total do código e a aplicação de patches é improvável. (Notícias do Hacker)

Do ponto de vista de um defensor, a questão prática não é "isso é explorável?" (é), mas "Meu avião de gerenciamento está acessível?" Muitos gateways DSL para consumidores expõem pontos de extremidade CGI administrativos somente na LAN por padrão. A BleepingComputer observa que a exploração do CVE-2026-0625 pode implicar em um caminho baseado em navegador ou em um dispositivo configurado para administração remota, já que muitas configurações restringem os pontos de extremidade de gerenciamento, como dnscfg.cgi para redes locais. (BleepingComputer)

Dito isso, o comprometimento do dispositivo de borda não exige que o administrador de WAN esteja habilitado em todos os cenários. Quando um invasor consegue se firmar em uma rede (phishing, um endpoint comprometido, uma extensão mal-intencionada ou um serviço exposto), a interface do usuário da Web do roteador se torna um alvo de alto potencial. O motivo é Controle de DNSSe um invasor puder alterar os resolvedores de DNS no gateway, todos os dispositivos downstream herdarão um primitivo de direcionamento de tráfego silencioso.

Os próprios registros históricos da D-Link vinculam essa classe de comportamento a GhostDNS/DNSChanger campanhas: adivinhação de senhas em relação a credenciais padrão (por exemplo, admin/admin), verificação de caminhos CGI expostos, como dnscfg.cgie, em seguida, reescrevendo os valores de DNS para redirecionar os usuários para a infraestrutura do invasor. (supportannouncement.us.dlink.com)

O que fazer hoje: verificação segura sem transformar o bug em uma arma

Abaixo está um fluxo de trabalho defensável para equipes de segurança. Ele se concentra em identificação da exposição e Verificações de integridade do DNS-não explorar a reprodução.

Etapa 1: Encontre sua exposição potencial ao plano de gerenciamento

Comece com a descoberta de ativos:

• IPs voltados para a Internet que expõem HTTP(S) em portas comuns e incomuns (80/443/8080/8443, etc.).
• Filiais e configurações de conectividade "temporárias" (os locais onde os gateways legados persistem).
• Registros DNS públicos que mapeiam os pontos de extremidade de gerenciamento do CPE (ocasionalmente rotulados erroneamente como "monitoramento" ou "administrador").

Etapa 2: Verifique se dnscfg.cgi é acessível (sem cargas úteis)

Esse snippet Python executa uma verificação simples de acessibilidade e de limites de autenticação.

solicitações de importação

def probe_dnscfg(base_url: str, timeout=6):
    url = base_url.rstrip("/") + "/dnscfg.cgi"
    try:
        r = requests.get(url, timeout=timeout, allow_redirects=False)
        return {
            "url": url,
            "status": r.status_code,
            "server": r.headers.get("Server", ""),
            "www_authenticate": r.headers.get("WWW-Authenticate", ""),
            "location": r.headers.get("Location", ""),
        }
    exceto requests.RequestException as e:
        return {"url": url, "error": str(e)}

targets = [
    "",
    # "",
]

for t in targets:
    print(probe_dnscfg(t))

Dicas de interpretação:

• 200 sem autenticação → seu plano de gerenciamento pode estar perigosamente exposto.
• 401/302 para fazer login → ainda é de alto risco se as credenciais forem fracas, reutilizadas ou padrão.
• Erros/tempo limite → podem indicar filtragem, serviço não HTTP ou simplesmente não estar presente.

Etapa 3: Trate as alterações de DNS como um indicador primário de comprometimento

Como o CVE-2026-0625 está no caminho da configuração do DNS, "meus resolvedores foram alterados?" é a pergunta de detecção mais prática. A D-Link descreve explicitamente os fluxos de trabalho do DNSChanger como a reescrita do DNS do roteador para redirecionar o tráfego bancário e outros tráfegos de alto valor. (supportannouncement.us.dlink.com)

Operacionalmente:

• Valide os resolvedores de DNS configurados pelo roteador em relação à sua linha de base aprovada.
• Validar o DNS manipulado por DHCP nos clientes da amostra (Windows ipconfig /all, macOS scutil --dns).
• Alerta sobre mudanças repentinas de resolvedores, especialmente para intervalos residenciais ou ASNs incomuns.

Mitigação quando a aplicação de patches não é uma opção: um manual de prioridades

A cobertura e as mensagens dos fornecedores enfatizam que os modelos afetados são antigos e devem ser substituídos; a SecurityWeek afirma explicitamente que Nenhum patch será lançado e aconselha os proprietários a reformar e substituir. (SecurityWeek)

Uma escada de mitigação pragmática:

1) Substituir (o único estado final limpo).

Se o dispositivo for EOL/EOS, a modernização é a redução de risco que você pode realmente medir.

2) Reduzir a superfície de ataque.

Desative o administrador do lado da WAN, bloqueie o acesso de entrada às portas de gerenciamento na borda do ISP e restrinja o acesso do administrador a uma VLAN de gerenciamento reforçada.

3) Raio de explosão do segmento.

Separe o gerenciamento do roteador, os pontos de extremidade do usuário, a IoT e as redes de convidados. Suponha que ocorra um comprometimento interno; projete-o de modo que não se torne o controle de tudo pelo DNS.

4) Higiene das credenciais.

As credenciais padrão e as senhas fracas continuam sendo um tema recorrente nas narrativas do GhostDNS/DNSChanger. (supportannouncement.us.dlink.com)

5) Controles de integridade do DNS.

Sempre que possível, aplique resolvedores aprovados e monitore os desvios. Mesmo que um gateway legado esteja comprometido, sua detecção deve ser acionada em caso de desvio do resolvedor.

CVEs relacionados: o padrão mais amplo para o qual você deve otimizar

O CVE-2026-0625 se encaixa em um modelo de exploração recorrente: dispositivo de borda + gerenciamento da Web + injeção/desvio + varredura compatível com automação. Esse padrão é o motivo pelo qual esses problemas atraem a atenção das botnets e pelo qual o "EOL" é um multiplicador tão doloroso.

Alguns paralelos de alto sinal:

• CVE-2023-1389 (TP-Link Archer AX21): O NVD descreve uma injeção de comando não autenticada na interface de gerenciamento da Web, e a TP-Link reconhece os relatos de que o CVE foi adicionado ao arsenal do botnet Mirai. (NVD)
• CVE-2024-3400 (Palo Alto Networks PAN-OS GlobalProtect): A consultoria da PAN apresenta isso como uma cadeia que leva à execução de código em nível de raiz para configurações específicas, ilustrando como o "RCE de borda" passa do perímetro do consumidor para o perímetro da empresa. (security.paloaltonetworks.com)
• CVE-2024-12987 (DrayTek Vigor): Armis o descreve como uma injeção crítica de comando do sistema operacional em um manipulador de gerenciamento da Web do roteador. (Armis)

Se estiver criando uma rubrica de priorização de vulnerabilidades, considere codificar isso como uma regra: As vulnerabilidades do plano de gerenciamento em dispositivos de borda recebem prioridade elevadaMesmo quando os produtos afetados são "apenas alguns roteadores", porque o controle que eles fornecem (DNS, roteamento, NAT) amplia o comprometimento downstream.

Fluxo de trabalho com penalidade: Da descoberta de ativos ao relatório da cadeia de evidências

Se o seu fluxo de trabalho inclui a Penligent, o CVE-2026-0625 é um forte candidato para um pipeline repetível de exposição a evidênciasO Penligent oferece uma solução de teste de DNS que permite que os usuários descubram superfícies de administração acessíveis pela Internet, identifiquem e correlacionem ativos de borda e gerem um relatório de cadeia de evidências mostrando onde os planos de gerenciamento podem ser acessados e se existe um comportamento suspeito de configuração de DNS. O posicionamento público e a documentação da Penligent enfatizam os testes orquestrados e a geração de relatórios em fluxos de trabalho de ponta a ponta. (Penligente)

Na prática, o valor não é a "exploração em um clique". Ele é operacional: transformar a realidade confusa dos dispositivos de borda legados em um programa de correção rastreável (substituir, restringir, segmentar), apoiado por artefatos que seus proprietários de TI podem usar.

Links de referência autorizados

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-0625 (NVD)
• Aviso da D-Link (SAP10488): https://supportannouncement.us.dlink.com/security/publication.aspx?name=SAP10488 (supportannouncement.us.dlink.com)
• Aviso do VulnCheck: https://www.vulncheck.com/advisories/dlink-dsl-command-injection-via-dns-configuration-endpoint (VulnCheck)
• CWE-78: https://cwe.mitre.org/data/definitions/78.html (NVD)
• Cobertura do BleepingComputer (versões + contexto do ciclo de vida): https://www.bleepingcomputer.com/news/security/new-d-link-flaw-in-legacy-dsl-routers-actively-exploited-in-attacks/ (BleepingComputer)