6 CVEs Graves no dnsmasq: Seu Linux, Docker e Pi-hole Estão Vulneráveis Agora

Se você roda Linux em produção — e convenhamos, quem não roda? — tem uma boa chance de que o dnsmasq esteja ali, silencioso, resolvendo DNS e distribuindo DHCP sem que ninguém preste atenção nele. Pois bem, o CERT acabou de soltar 6 CVEs de uma vez para esse software, e as falhas são sérias: DNS cache poisoning, escalação de privilégios para root, crashes remotos e vazamento de memória.

O dnsmasq é daqueles softwares invisíveis que estão em literalmente tudo. Roteadores domésticos, containers Docker, Pi-hole, OpenWrt, Android, praticamente toda distro Linux usa ou já usou em algum momento. E os bugs que o CERT revelou não são novos — são falhas antigas que estavam lá “em praticamente todas as versões não-antigas”, nas palavras do próprio mantenedor Simon Kelley.

Eu já vi cenários onde DNS poisoning derrubou a infraestrutura inteira de uma empresa. E com essas falhas, o atacante nem precisa ser tão sofisticado assim.

O Que é o dnsmasq (e Por Que Ele Está em Todo Lugar)

Para quem não conhece, o dnsmasq é um servidor DNS e DHCP leve, projetado para redes pequenas e médias. Ele faz cache de consultas DNS, distribui endereços IP via DHCP e DHCPv6, e serve como servidor TFTP para boot PXE. Tudo isso com um footprint mínimo — consome poucos MB de RAM e roda em hardware embarcado sem problema.

A questão é que “redes pequenas” virou um eufemismo. O dnsmasq está em:

• Roteadores domésticos — Asus, TP-Link, Netgear, basicamente qualquer roteador com firmware baseado em Linux
• OpenWrt — o firmware open source mais popular para roteadores
• Pi-hole — o bloqueador de anúncios por DNS que virou queridinho da comunidade
• Docker — o daemon do Docker usa dnsmasq (ou sua variante) para resolução DNS interna de containers
• libvirt/KVM — máquinas virtuais usam dnsmasq para rede NAT
• NetworkManager — muitas distros Linux usam dnsmasq como backend de DNS
• Android — sim, seu celular também
• Red Hat, Ubuntu, SUSE, Arch, NixOS — todas as grandes distros empacotam o dnsmasq

Quando um software tão ubíquo tem 6 falhas de segurança graves descobertas de uma vez, a superfície de ataque é gigantesca.

As 6 Falhas: Uma Pior que a Outra

O advisory do CERT (VU#471747) catalogou 6 vulnerabilidades distintas. Vou passar por cada uma com o nível de detalhe que importa na prática.

CVE-2026-2291 — Heap Overflow no extract_name() (DNS Cache Poisoning)

Essa é a mais perigosa do lote. A função extract_name() é responsável por parsear nomes de domínio nas respostas DNS. Um heap buffer overflow nessa função permite que um atacante injete entradas falsas no cache DNS do dnsmasq.

Na prática, isso significa que um atacante pode fazer o seguinte:

1. Envia uma resposta DNS malformada para o dnsmasq
2. O overflow no heap corrompe as estruturas de cache
3. O dnsmasq passa a responder com o IP do atacante para um domínio legítimo
4. Todos os clientes que usam esse dnsmasq são redirecionados

Imagine um cenário corporativo: o dnsmasq da rede interna é envenenado, e todas as requisições para banco.com.br passam a apontar para um servidor do atacante com um certificado Let’s Encrypt válido para um domínio parecido. Phishing em escala industrial.

# Verificar se o dnsmasq está rodando no seu sistema
ps aux | grep dnsmasq

# Verificar a versão instalada
dnsmasq --version | head -1

# Se a versão for anterior a 2.92rel2, você está vulnerável

CVE-2026-4890 — Loop Infinito na Validação DNSSEC (DoS Remoto)

Se você habilitou DNSSEC no dnsmasq (e deveria ter habilitado), essa falha permite que um atacante trave o serviço completamente. Um pacote DNS especialmente crafted faz a validação DNSSEC entrar em um loop infinito, consumindo 100% de CPU e parando de responder qualquer query.

O resultado? Denial of Service. Todos os clientes perdem resolução DNS. Em um ambiente onde o dnsmasq é o único resolver — como em muitas redes domésticas e setups de container — isso significa perda total de conectividade.

# Verificar se DNSSEC está habilitado no dnsmasq
grep -i dnssec /etc/dnsmasq.conf /etc/dnsmasq.d/*

# Se encontrar "dnssec" nas configurações, o DoS remoto é possível

CVE-2026-4891 — Out-of-Bounds Read na Validação DNSSEC (Leak de Memória)

Outra falha na validação DNSSEC, mas essa vaza informação em vez de travar. Um atacante remoto pode enviar pacotes DNS que fazem o dnsmasq ler memória heap além dos limites do buffer, expondo dados que não deveriam ser acessíveis.

Dependendo do que está na memória adjacente, o atacante pode obter:

• Endereços de memória (úteis para bypass de ASLR)
• Fragmentos de queries DNS de outros clientes
• Tokens ou dados de sessão em memória

CVE-2026-4892 — Heap Write no DHCPv6 (Escalação para Root Local)

Essa é a mais assustadora para quem roda dnsmasq como serviço de DHCP. Uma vulnerabilidade de heap-based out-of-bounds write na implementação DHCPv6 permite que um atacante local execute código arbitrário com privilégios de root.

O dnsmasq precisa rodar como root para fazer bind em portas privilegiadas (53 para DNS, 67 para DHCP). Embora ele tenha a opção de dropar privilégios depois de iniciar, muitas instalações default mantêm root. Isso significa que um atacante com acesso à rede local — mesmo um dispositivo IoT comprometido — pode explorar o DHCPv6 para ganhar root no servidor que roda dnsmasq.

# Verificar com qual usuário o dnsmasq está rodando
ps -eo user,pid,comm | grep dnsmasq

# Se mostrar "root", a escalação de privilégios é direta
# Se mostrar "dnsmasq" ou "nobody", o dano é limitado (mas ainda sério)

CVE-2026-4893 — Bypass de Source Check via Client-Subnet (Disclosure)

Essa falha explora o suporte ao RFC 7871 (EDNS Client Subnet). Um atacante pode craftar pacotes DNS com informações de client-subnet que fazem o dnsmasq bypassar as verificações de origem das respostas.

O impacto direto é information disclosure — o atacante consegue obter informações sobre a topologia da rede interna, subnets configuradas e clientes que estão fazendo queries. Mas o impacto indireto é pior: esse bypass pode ser encadeado com o CVE-2026-2291 para facilitar o cache poisoning.

CVE-2026-5172 — Buffer Overflow no extract_addresses() (Crash Remoto)

A última CVE é outro buffer overflow, dessa vez na função extract_addresses(). Uma resposta DNS malformada pode causar um heap out-of-bounds read que crasha o dnsmasq.

Embora “apenas” causar um crash pareça menos grave que execução de código, lembre que crashar o dnsmasq significa derrubar DNS e DHCP de toda a rede de uma vez. E se o serviço reiniciar automaticamente via systemd, o atacante pode crashar repetidamente, criando uma janela onde o cache está limpo — facilitando o poisoning do CVE-2026-2291.

A Tabela Completa

Cinco das seis falhas são exploráveis remotamente. Isso não é um detalhe — significa que qualquer servidor dnsmasq exposto pode ser atacado pela internet.

Por Que DNS Cache Poisoning É Tão Perigoso

Vou ser direto: DNS cache poisoning é um dos ataques mais subestimados da internet moderna. Todo mundo foca em SQL injection, XSS, phishing por e-mail — mas envenenar o DNS é como envenenar a água: afeta todo mundo que bebe.

Quando o cache DNS do dnsmasq é envenenado, o que acontece é simples e devastador:

1. Um cliente pergunta “qual o IP de github.com?”
2. O dnsmasq, com o cache envenenado, responde com o IP do atacante
3. O cliente se conecta ao servidor do atacante achando que é o GitHub
4. Se o atacante tiver um certificado TLS válido (fácil de obter via Let’s Encrypt para um domínio similar), o usuário nem percebe

O dnsmasq historicamente usa validação fraca para matching de respostas DNS. Ele salva apenas o hash da question section e, se o atacante acertar o transaction ID e a source port, o dnsmasq sobrescreve o endereço em cache independente do TTL anterior. Versões compiladas sem DNSSEC usam CRC32 como hash — um algoritmo que foi projetado para detecção de erros, não para segurança.

# Demonstração conceitual de como CRC32 é fraco para segurança
import binascii

# CRC32 tem apenas 2^32 valores possíveis (~4 bilhões)
# Com hardware moderno, brute force é trivial
domain = b"github.com"
crc = binascii.crc32(domain)
print(f"CRC32 de '{domain.decode()}': {crc:#010x}")
# Um atacante pode pré-computar colisões facilmente

Como Verificar Se Você Está Vulnerável

O checklist é simples:

# 1. O dnsmasq está instalado?
which dnsmasq && echo "INSTALADO" || echo "NÃO ENCONTRADO"

# 2. Qual versão?
dnsmasq --version 2>/dev/null | head -1
# Se for anterior a 2.92rel2, você precisa atualizar

# 3. Está rodando agora?
systemctl status dnsmasq 2>/dev/null || service dnsmasq status 2>/dev/null

# 4. Quem mais está usando dnsmasq no sistema?
# Docker, libvirt, NetworkManager podem rodar instâncias próprias
ps aux | grep dnsmasq | grep -v grep

# 5. Verificar Pi-hole
pihole -v 2>/dev/null
# Pi-hole empacota sua própria versão do dnsmasq (pihole-FTL)

Pi-hole: Atenção Especial

O Pi-hole usa um fork do dnsmasq chamado pihole-FTL. Os mantenedores do Pi-hole precisam incorporar os patches e lançar uma atualização. Se você roda Pi-hole, monitore o repositório oficial:

# Atualizar Pi-hole (quando o patch estiver disponível)
pihole -up

# Enquanto isso, considere restringir o acesso ao Pi-hole
# para apenas a rede local via firewall
iptables -A INPUT -p udp --dport 53 ! -s 192.168.1.0/24 -j DROP
iptables -A INPUT -p tcp --dport 53 ! -s 192.168.1.0/24 -j DROP

Docker e Containers

O Docker usa dnsmasq (ou uma implementação similar) para DNS interno. Se você roda containers em produção:

# Verificar o DNS resolver dentro de um container
docker run --rm alpine cat /etc/resolv.conf

# Verificar se o Docker daemon usa dnsmasq
docker info 2>/dev/null | grep -i dns

Como Corrigir

Atualização Direta

A versão corrigida é a 2.92rel2. O mantenedor Simon Kelley também está preparando a versão 2.93, que inclui reescritas mais profundas das áreas afetadas.

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade dnsmasq

# Red Hat/CentOS/Fedora
sudo dnf update dnsmasq

# Arch Linux
sudo pacman -Syu dnsmasq

# Alpine (Docker base images)
apk update && apk upgrade dnsmasq

# Após atualizar, reiniciar o serviço
sudo systemctl restart dnsmasq

Mitigações Temporárias

Se a atualização não está disponível ainda na sua distro:

# 1. Habilitar DNSSEC (mitiga parcialmente o cache poisoning)
# Adicionar em /etc/dnsmasq.conf:
echo "dnssec" >> /etc/dnsmasq.conf
echo "trust-anchor=.,20326,8,2,E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D" >> /etc/dnsmasq.conf

# 2. Restringir interfaces (reduz superfície de ataque)
echo "bind-interfaces" >> /etc/dnsmasq.conf
echo "listen-address=127.0.0.1" >> /etc/dnsmasq.conf

# 3. Dropar privilégios (mitiga CVE-2026-4892)
echo "user=dnsmasq" >> /etc/dnsmasq.conf
echo "group=dnsmasq" >> /etc/dnsmasq.conf

# 4. Limitar o cache (reduz janela de poisoning)
echo "cache-size=150" >> /etc/dnsmasq.conf

# Reiniciar após as mudanças
sudo systemctl restart dnsmasq

Para Roteadores com OpenWrt

# Conectar via SSH no roteador
ssh root@192.168.1.1

# Atualizar o feed de pacotes
opkg update

# Atualizar o dnsmasq
opkg upgrade dnsmasq-full
# ou
opkg upgrade dnsmasq

# Reiniciar
/etc/init.d/dnsmasq restart

Não É a Primeira Vez — E Não Vai Ser a Última

Quem acompanha segurança há mais tempo vai lembrar do DNSpooq em janeiro de 2021, quando 7 CVEs foram reveladas no dnsmasq de uma vez. Naquela ocasião, pesquisadores da JSOF estimaram que milhões de dispositivos estavam vulneráveis. As falhas de 2021 também envolviam cache poisoning e buffer overflows — um padrão que se repete agora em 2026.

O problema de fundo é que o dnsmasq é escrito em C, com manipulação manual de memória e parsing de protocolos binários complexos (DNS, DHCP, DNSSEC). É a receita clássica para vulnerabilidades de memória. Simon Kelley mantém o projeto praticamente sozinho há mais de 20 anos, e a base de código, embora relativamente pequena (~15.000 linhas), lida com protocolos que têm edge cases em cima de edge cases.

A questão que a comunidade precisa se fazer é: faz sentido que um dos softwares mais críticos da infraestrutura da internet seja mantido por uma pessoa? Não é culpa do Simon — o trabalho dele é extraordinário. Mas a realidade é que projetos de infraestrutura crítica precisam de funding e revisão de segurança proporcionais à sua importância.

Vendors Afetados

De acordo com o advisory do CERT, os seguintes vendors confirmaram ser afetados ou estão investigando:

Mais de 25 vendors adicionais estão listados como “status desconhecido” no advisory do CERT. Se você usa qualquer appliance de rede, roteador ou firewall baseado em Linux, vale verificar com o fabricante.

O Que Fazer Agora: Plano de Ação em 5 Minutos

Não tem desculpa para esperar. Essas falhas já são públicas e os detalhes técnicos estão disponíveis — é questão de tempo até exploits aparecerem in the wild.

#!/bin/bash
# Script rápido de verificação e mitigação
echo "=== dnsmasq Security Check ==="

# Verificar instalação
if command -v dnsmasq &>/dev/null; then
    VERSION=$(dnsmasq --version | head -1)
    echo "[!] dnsmasq encontrado: $VERSION"

    # Verificar processos
    PROCS=$(pgrep -c dnsmasq)
    echo "[i] Instâncias rodando: $PROCS"

    # Verificar usuário
    ps -eo user,comm | grep dnsmasq | sort -u

    echo ""
    echo "AÇÃO NECESSÁRIA:"
    echo "1. Atualizar para >= 2.92rel2"
    echo "2. Restringir listen-address"
    echo "3. Configurar user=dnsmasq"
    echo "4. Monitorar logs: journalctl -u dnsmasq -f"
else
    echo "[OK] dnsmasq não encontrado diretamente"
    echo "[!] Verificando em containers e serviços..."
    docker ps 2>/dev/null | grep -i dns
    ps aux | grep dnsmasq | grep -v grep
fi

A vulnerabilidade mais urgente é o CVE-2026-2291 (cache poisoning). Se você não pode atualizar imediatamente, ao menos restrinja o dnsmasq para escutar apenas em interfaces internas e habilite DNSSEC. Não é uma solução completa — o CVE-2026-4890 é justamente um DoS no DNSSEC — mas reduz significativamente o vetor de ataque mais perigoso.

E se você é daqueles que roda Pi-hole como DNS da casa inteira, fica o alerta: até o pihole-FTL ser patcheado, considere adicionar um firewall rule bloqueando tráfego DNS externo no seu Pi-hole. Só sua rede local deveria poder fazer queries.

Fonte de inspiração: CERT Advisory VU#471747 e Hacker News discussion