netty-resolver-dns-check

Checker statico offline che ispeziona i jar Java pacchettizzati per individuare versioni vulnerabili di netty-resolver-dns e rileva se Spring WebClient utilizza effettivamente il resolver DNS di Netty.

E non è solo sul classpath. L'HttpClient di Reactor Netty — il connettore che Spring Boot sceglie per WebClient ogni volta che Reactor Netty è presente — risolve i nomi host con il DnsAddressResolverGroup di Netty, non con il resolver della JDK:

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

(Lo stesso in reactor-netty 1.1.x, 1.2.x, 1.3.x e main.) L'ordine di rilevamento dei connettori di Spring Boot è reactor > jetty > httpComponents > jdk, quindi Reactor Netty vince ogni volta che è presente.

Non ci siamo fermati alla lettura del codice sorgente. Nell'esperimento controllato di seguito, un'app Spring Boot 3.5.14 predefinita che effettua una richiesta WebClient ha inviato una vera query DNS attraverso il resolver di Netty (WRITE: UDP ... DefaultDnsQuestion(example.com.)).

Gli advisory per CVE-2026-45674 e CVE-2026-47691 lo dicono chiaramente: "Qualsiasi applicazione che utilizza il resolver DNS di Netty è interessata."

2. Quali versioni di Spring Boot includono un default interessato

Tutte e tre le CVE condividono la stessa correzione: 4.1.135.Final (linea 4.1) / 4.2.15.Final (linea 4.2). Letto da ciascun spring-boot-dependencies-<v>.pom (<netty.version>), 2026-09-11:

Le versioni corrette sono tutte su Maven Central. L'aggiornamento funziona; questo strumento non afferma il contrario.

3. Cosa può e cosa non può dirti la scansione statica

Un numero di versione è una riga di mvn dependency:tree. La domanda più difficile è se il resolver è realmente in uso. Così abbiamo creato quattro veri fat jar Spring Boot 3.5.14 e uno su 3.5.16, e misurato la verità effettiva — le query DNS realmente inviate da Netty — rispetto a ciò che questo strumento deduce dal solo jar:

Il risultato onesto: lo strumento dice in modo affidabile "in uso" quando non c'è override, e trova tracce di override nel tuo codice e nella configurazione (3 su 3, nessun falso positivo su A). Non può distinguere B (tutto sovrascritto) da D (un client ancora sul default) — la loro evidenza nel bytecode è identica. Quindi un override non lo fa mai dire "non interessato"; dice "verificare manualmente", e ti dà il controllo di un minuto qui sotto.

L'autoverifica di un minuto

1. Avvia la tua app con --logging.level.io.netty.resolver.dns=DEBUG
2. Falle inviare una richiesta in uscita attraverso ogni WebClient che hai
3. Cerca WRITE: UDP nel log — presente: il resolver di Netty è in uso; assente: quella richiesta non lo ha usato

Non giudicare da "è stato caricato DnsNameResolver?". L'app B ha sostituito il resolver e ha comunque caricato quella classe, perché il resolver group predefinito viene costruito in modo eager. Solo le righe delle query sono prova.

Utilizzo

Legge ciò che è effettivamente pacchettizzato (fat jar BOOT-INF/lib, war WEB-INF/lib, jar annidati), non pom.xml — la dipendenza è transitiva, quindi il pom ti direbbe che non c'è. La presenza è decisa dalla classe io/netty/resolver/dns/DnsNameResolver.class, non dai manifest di versione. Le tracce di override vengono cercate solo nelle tue classi e in application*.properties/yml (i jar delle librerie fanno riferimento a queste classi stesse).

L'output è in cinese; le righe di verdetto e gli id CVE sono ciò su cui gli script dovrebbero basarsi.

Cosa non ti dice

• Se un attaccante può raggiungerti. CVE-2026-47691, dall'advisory: un attaccante che controlla un name server autoritativo per un sottodominio può avvelenare la cache per i domini padre — quindi la tua app deve risolvere un nome controllato dall'attaccante (per esempio, recuperando URL forniti dall'utente). CVE-2026-45673 è medium (6.8) e richiede risposte falsificate per raggiungere il tuo resolver. Gravità per advisory: due high (8.7), una medium.
• Gli override impostati tramite variabili d'ambiente, o all'interno di un jar di libreria, sono invisibili a una scansione statica. Lo strumento propende per "in uso" in quei casi.
• Le librerie che usano direttamente l'HttpClient di Reactor Netty (per esempio un gateway) non sono analizzate separatamente — se Reactor Netty è presente, si presume il percorso predefinito.
• Le versioni al di fuori delle linee 4.1 e 4.2 sono segnalate come "impossibile giudicare", non indovinate.

Da dove provengono le regole

GitHub advisory API, letto 2026-09-11:

La tabella di Spring Boot è in BootTable.java; un unit test ri-deriva le tre affermazioni della sezione 2 da essa, così la tabella e le affermazioni non possono divergere silenziosamente.

L'esperimento controllato

evidence/ contiene le cinque app (A–E) e runtime.sh, che conta le righe WRITE: UDP per app. tools/e2e_real_jars.py esegue questo strumento sugli stessi cinque jar e verifica ogni verdetto. La compilazione delle app richiede Maven 3.6.3 o successivo.

Codici di uscita

Licenza

Apache License 2.0