netty-resolver-dns-check

Verificador estático offline que inspeciona jars Java empacotados em busca de versões vulneráveis do netty-resolver-dns e detecta se o Spring WebClient realmente usa o resolvedor DNS do Netty.

E ele não está apenas no classpath. O HttpClient do Reactor Netty — o conector que o Spring Boot escolhe para o WebClient sempre que o Reactor Netty está presente — resolve nomes de host com o próprio DnsAddressResolverGroup do Netty, não com o resolver da JDK:

• HttpClientConfig.defaultAddressResolverGroup() → HttpResources.getOrCreateDefaultResolver()
• TcpResources.getOrCreateDefaultResolver() → NameResolverProvider.newNameResolverGroup(...)
• NameResolverProvider.newNameResolverGroup → new DnsNameResolverBuilder() → new DnsAddressResolverGroup(builder)

(O mesmo em reactor-netty 1.1.x, 1.2.x, 1.3.x e main.) A ordem de detecção de conectores do Spring Boot é reactor > jetty > httpComponents > jdk, então o Reactor Netty vence sempre que está presente.

Não paramos na leitura do código-fonte. No experimento controlado abaixo, um app padrão Spring Boot 3.5.14 fazendo uma requisição WebClient enviou uma consulta DNS real através do resolver do Netty (WRITE: UDP ... DefaultDnsQuestion(example.com.)).

Os avisos para CVE-2026-45674 e CVE-2026-47691 dizem claramente: "Qualquer aplicação que use o resolver DNS do Netty é impactada."

2. Quais versões do Spring Boot trazem um padrão afetado

Todas as três CVEs compartilham a mesma correção: 4.1.135.Final (linha 4.1) / 4.2.15.Final (linha 4.2). Lido de cada spring-boot-dependencies-<v>.pom (<netty.version>), 2026-09-11:

As versões corrigidas estão todas no Maven Central. A atualização funciona; esta ferramenta não afirma o contrário.

3. O que a varredura estática pode e não pode lhe dizer

Um número de versão é uma linha de mvn dependency:tree. A pergunta mais difícil é se o resolver está realmente em uso. Então construímos quatro fat jars reais de Spring Boot 3.5.14 e um em 3.5.16, e medimos a verdade absoluta — consultas DNS realmente enviadas pelo Netty — contra o que esta ferramenta infere apenas do jar:

O resultado honesto: a ferramenta diz de forma confiável "em uso" quando não há override, e encontra vestígios de override no seu código e configuração (3 de 3, sem falso positivo em A). Ela não consegue distinguir B (tudo sobrescrito) de D (um cliente ainda no padrão) — as evidências de bytecode são idênticas. Então um override nunca faz com que ela diga "não afetado"; ela diz "verificar manualmente", e fornece a verificação de um minuto abaixo.

A autoverificação de um minuto

1. Inicie sua aplicação com --logging.level.io.netty.resolver.dns=DEBUG
2. Faça-a enviar uma requisição de saída através de cada WebClient que você tiver
3. Procure por WRITE: UDP no log — presente: o resolver do Netty está em uso; ausente: aquela requisição não o usou

Não julgue por "o DnsNameResolver foi carregado?". O App B substituiu o resolver e ainda carregou essa classe, porque o grupo de resolvers padrão é construído antecipadamente. Apenas as linhas de consulta são prova.

Uso

Ele lê o que está realmente empacotado (fat jar BOOT-INF/lib, war WEB-INF/lib, jars aninhados), não o pom.xml — a dependência é transitiva, então o pom diria que ela não está lá. A presença é decidida pela classe io/netty/resolver/dns/DnsNameResolver.class, não por manifestos de versão. Vestígios de override são procurados apenas nas suas próprias classes e em application*.properties/yml (jars de bibliotecas referenciam essas classes por conta própria).

A saída está em chinês; as linhas de veredito e os ids das CVEs são o que os scripts devem usar como chave.

O que ela não lhe diz

• Se um atacante consegue alcançá-lo. CVE-2026-47691, do aviso: um atacante que controla um servidor de nomes autoritativo para um subdomínio pode envenenar o cache de domínios pais — então sua aplicação precisa resolver um nome que o atacante controla (por exemplo, buscando URLs fornecidas pelo usuário). CVE-2026-45673 é média (6.8) e precisa de respostas falsificadas para alcançar seu resolver. Severidade por aviso: duas altas (8.7), uma média.
• Overrides definidos por variáveis de ambiente, ou dentro de um jar de biblioteca, são invisíveis para uma varredura estática. A ferramenta tende a "em uso" nesses casos.
• Bibliotecas que usam o HttpClient do Reactor Netty diretamente (por exemplo, um gateway) não são analisadas separadamente — se o Reactor Netty está presente, o caminho padrão é assumido.
• Versões fora das linhas 4.1 e 4.2 são reportadas como "não é possível julgar", não adivinhadas.

De onde vêm as regras

API de avisos do GitHub, lida em 2026-09-11:

A tabela do Spring Boot está em BootTable.java; um teste unitário re-deriva as três afirmações da seção 2 a partir dela, então a tabela e as afirmações não podem divergir silenciosamente.

O experimento controlado

evidence/ contém os cinco apps (A–E) e runtime.sh, que conta as linhas WRITE: UDP por app. tools/e2e_real_jars.py executa esta ferramenta contra os mesmos cinco jars e verifica cada veredito. Construir os apps requer Maven 3.6.3 ou mais recente.

Códigos de saída

Licença

Apache License 2.0