netty-resolver-dns-check

Vérificateur statique hors ligne qui inspecte les jars Java packagés à la recherche de versions vulnérables de netty-resolver-dns et détecte si Spring WebClient utilise réellement le résolveur DNS de Netty.

Et il n'est pas seulement présent dans le classpath. Le HttpClient de Reactor Netty — le connecteur que Spring Boot choisit pour WebClient dès que Reactor Netty est présent — résout les noms d'hôtes avec le DnsAddressResolverGroup de Netty, pas le résolveur du JDK :

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

(Idem dans reactor-netty 1.1.x, 1.2.x, 1.3.x et main.) L'ordre de détection des connecteurs de Spring Boot est reactor > jetty > httpComponents > jdk, donc Reactor Netty l'emporte dès qu'il est présent.

Nous ne nous sommes pas arrêtés à la lecture du code source. Dans l'expérience contrôlée ci-dessous, une application Spring Boot 3.5.14 par défaut effectuant une seule requête WebClient a envoyé une véritable requête DNS via le résolveur de Netty (WRITE: UDP ... DefaultDnsQuestion(example.com.)).

Les avis pour CVE-2026-45674 et CVE-2026-47691 le disent clairement : « Toute application utilisant le résolveur DNS de Netty est impactée. »

2. Quelles versions de Spring Boot embarquent un défaut affecté

Les trois CVE partagent le même correctif : 4.1.135.Final (branche 4.1) / 4.2.15.Final (branche 4.2). Lu depuis chaque spring-boot-dependencies-<v>.pom (<netty.version>), le 2026-09-11 :

Les versions corrigées sont toutes sur Maven Central. La mise à niveau fonctionne ; cet outil ne prétend pas le contraire.

3. Ce qu'un scan statique peut et ne peut pas vous dire

Un numéro de version, c'est une ligne de mvn dependency:tree. La question plus difficile est de savoir si le résolveur est réellement utilisé. Nous avons donc construit quatre véritables fat jars Spring Boot 3.5.14 et un en 3.5.16, et mesuré la vérité terrain — les requêtes DNS réellement envoyées par Netty — par rapport à ce que cet outil déduit du jar seul :

Le résultat honnête : l'outil dit de manière fiable « utilisé » lorsqu'il n'y a pas de surcharge, et il trouve des traces de surcharge dans votre code et votre configuration (3 sur 3, aucun faux positif sur A). Il ne peut pas distinguer B (tout surchargé) de D (un client toujours sur le défaut) — leurs preuves bytecode sont identiques. Une surcharge ne le fait donc jamais dire « non affecté » ; il dit « vérifier manuellement », et vous donne la vérification d'une minute ci-dessous.

L'auto-vérification en une minute

1. Démarrez votre application avec --logging.level.io.netty.resolver.dns=DEBUG
2. Faites-lui envoyer une requête sortante via chaque WebClient que vous avez
3. Cherchez WRITE: UDP dans le journal — présent : le résolveur de Netty est utilisé ; absent : cette requête ne l'a pas utilisé

Ne jugez pas sur « est-ce que DnsNameResolver a été chargé ? ». L'app B a remplacé le résolveur et a quand même chargé cette classe, car le groupe de résolveurs par défaut est construit de manière anticipée. Seules les lignes de requête sont une preuve.

Utilisation

Il lit ce qui est réellement empaqueté (fat jar BOOT-INF/lib, war WEB-INF/lib, jars imbriqués), pas pom.xml — la dépendance est transitive, donc le pom vous dirait qu'elle n'est pas là. La présence est déterminée par la classe io/netty/resolver/dns/DnsNameResolver.class, pas par les manifestes de version. Les traces de surcharge ne sont recherchées que dans vos propres classes et application*.properties/yml (les jars de bibliothèques référencent eux-mêmes ces classes).

La sortie est en chinois ; les lignes de verdict et les identifiants CVE sont ce sur quoi les scripts doivent se baser.

Ce qu'il ne vous dit pas

• Si un attaquant peut vous atteindre. CVE-2026-47691, d'après l'avis : un attaquant contrôlant un serveur de noms faisant autorité pour un sous-domaine peut empoisonner le cache pour les domaines parents — donc votre application doit résoudre un nom que l'attaquant contrôle (par exemple, récupérer des URL fournies par l'utilisateur). CVE-2026-45673 est moyenne (6.8) et nécessite des réponses usurpées pour atteindre votre résolveur. Sévérité selon l'avis : deux élevées (8.7), une moyenne.
• Les surcharges définies via des variables d'environnement, ou à l'intérieur d'un jar de bibliothèque, sont invisibles pour un scan statique. L'outil penche vers « utilisé » dans ces cas.
• Les bibliothèques qui utilisent directement le HttpClient de Reactor Netty (par exemple une passerelle) ne sont pas analysées séparément — si Reactor Netty est présent, le chemin par défaut est supposé.
• Les versions en dehors des branches 4.1 et 4.2 sont signalées comme « impossible à juger », pas devinées.

D'où viennent les règles

API des avis GitHub, consultée le 2026-09-11 :

La table Spring Boot se trouve dans BootTable.java ; un test unitaire redérive les trois affirmations de la section 2 à partir de celle-ci, de sorte que la table et les affirmations ne peuvent pas diverger silencieusement.

L'expérience contrôlée

evidence/ contient les cinq applications (A–E) et runtime.sh, qui compte les lignes WRITE: UDP par application. tools/e2e_real_jars.py exécute cet outil contre les mêmes cinq jars et vérifie chaque verdict. La compilation des applications nécessite Maven 3.6.3 ou plus récent.

Codes de sortie

Licence

Apache License 2.0