netty-resolver-dns-check

Offline-Statikprüfer, der gepackte Java-JARs auf anfällige Versionen von netty-resolver-dns untersucht und erkennt, ob Spring WebClient tatsächlich den DNS-Resolver von Netty verwendet.

Und es ist nicht nur im Classpath. Reactor Netty's HttpClient — der Connector, den Spring Boot für WebClient wählt, wann immer Reactor Netty vorhanden ist — löst Hostnamen mit Netty's eigenem DnsAddressResolverGroup auf, nicht mit dem JDK-Resolver:

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

(Gleiches in reactor-netty 1.1.x, 1.2.x, 1.3.x und main.) Die Connector-Erkennungsreihenfolge von Spring Boot ist reactor > jetty > httpComponents > jdk, also gewinnt Reactor Netty, wann immer es vorhanden ist.

Wir haben nicht beim Lesen des Quellcodes haltgemacht. Im unten beschriebenen kontrollierten Experiment sendete eine Standard-Spring-Boot-3.5.14-App, die eine einzige WebClient-Anfrage stellte, eine echte DNS-Abfrage über Netty's Resolver (WRITE: UDP ... DefaultDnsQuestion(example.com.)).

Die Advisories für CVE-2026-45674 und CVE-2026-47691 sagen es unverblümt: "Jede Anwendung, die Netty's DNS-Resolver verwendet, ist betroffen."

2. Welche Spring-Boot-Versionen einen betroffenen Standard ausliefern

Alle drei CVEs teilen denselben Fix: 4.1.135.Final (4.1-Zweig) / 4.2.15.Final (4.2-Zweig). Gelesen aus jeder spring-boot-dependencies-<v>.pom (<netty.version>), 2026-09-11:

Die behobenen Versionen sind alle auf Maven Central. Ein Upgrade funktioniert; dieses Werkzeug behauptet nichts anderes.

3. Was statisches Scannen Ihnen sagen kann und was nicht

Eine Versionsnummer ist eine Zeile aus mvn dependency:tree. Die schwierigere Frage ist, ob der Resolver wirklich verwendet wird. Also haben wir vier echte Spring-Boot-3.5.14-Fat-Jars gebaut und eines auf 3.5.16, und die Ground Truth gemessen — DNS-Abfragen, die tatsächlich von Netty gesendet werden — gegen das, was dieses Werkzeug allein aus dem Jar ableitet:

Das ehrliche Ergebnis: Das Werkzeug sagt zuverlässig "in Verwendung", wenn kein Override vorhanden ist, und es findet Override-Spuren in Ihrem Code und Ihrer Konfiguration (3 von 3, kein Fehlalarm bei A). Es kann B (alles überschrieben) nicht von D (ein Client noch auf dem Standard) unterscheiden — ihre Bytecode-Evidenz ist identisch. Ein Override führt also nie dazu, dass es "nicht betroffen" sagt; es sagt "manuell prüfen" und gibt Ihnen die Ein-Minuten-Prüfung unten.

Die Ein-Minuten-Selbstprüfung

1. Starten Sie Ihre App mit --logging.level.io.netty.resolver.dns=DEBUG
2. Sorgen Sie dafür, dass sie eine ausgehende Anfrage über jeden WebClient sendet, den Sie haben
3. Suchen Sie nach WRITE: UDP im Log — vorhanden: Netty's Resolver wird verwendet; nicht vorhanden: diese Anfrage hat ihn nicht verwendet

Urteilen Sie nicht danach, ob "wurde DnsNameResolver geladen?". App B ersetzte den Resolver und lud diese Klasse trotzdem, weil die Standard-Resolver-Gruppe eifrig aufgebaut wird. Nur die Abfragezeilen sind Beweis.

Verwendung

Es liest, was tatsächlich gepackt ist (Fat-Jar BOOT-INF/lib, War WEB-INF/lib, verschachtelte Jars), nicht pom.xml — die Abhängigkeit ist transitiv, die Pom würde Ihnen also sagen, dass sie nicht da ist. Das Vorhandensein wird durch die Klasse io/netty/resolver/dns/DnsNameResolver.class entschieden, nicht durch Versions- Manifeste. Override-Spuren werden nur in Ihren eigenen Klassen und application*.properties/yml gesucht (Bibliotheks-Jars referenzieren diese Klassen selbst).

Die Ausgabe ist auf Chinesisch; die Verdict-Zeilen und CVE-IDs sind das, worauf Skripte sich stützen sollten.

Was es Ihnen nicht sagt

• Ob ein Angreifer Sie erreichen kann. CVE-2026-47691, aus dem Advisory: Ein Angreifer, der einen autoritativen Namensserver für eine Subdomain kontrolliert, kann den Cache für übergeordnete Domains vergiften — Ihre App muss also einen Namen auflösen, den der Angreifer kontrolliert (zum Beispiel das Abrufen benutzerseitig gelieferter URLs). CVE-2026-45673 ist medium (6.8) und benötigt gefälschte Antworten, um Ihren Resolver zu erreichen. Schweregrad laut Advisory: zwei hoch (8.7), einer medium.
• Overrides, die über Umgebungsvariablen oder innerhalb eines Bibliotheks-Jars gesetzt werden, sind für einen statischen Scan unsichtbar. Das Werkzeug neigt in diesen Fällen zu "in Verwendung".
• Bibliotheken, die Reactor Netty's HttpClient direkt verwenden (zum Beispiel ein Gateway), werden nicht separat analysiert — wenn Reactor Netty vorhanden ist, wird der Standardpfad angenommen.
• Versionen außerhalb der 4.1- und 4.2-Zweige werden als "kann nicht beurteilen" gemeldet, nicht geraten.

Woher die Regeln stammen

GitHub-Advisory-API, gelesen 2026-09-11:

Die Spring-Boot-Tabelle steht in BootTable.java; ein Unit-Test leitet die drei Aussagen in Abschnitt 2 daraus erneut ab, sodass Tabelle und Behauptungen nicht stillschweigend auseinanderdriften können.

Das kontrollierte Experiment

evidence/ enthält die fünf Apps (A–E) und runtime.sh, das WRITE: UDP-Zeilen pro App zählt. tools/e2e_real_jars.py führt dieses Werkzeug gegen dieselben fünf Jars aus und prüft jedes Verdict. Das Bauen der Apps erfordert Maven 3.6.3 oder neuer.

Exit-Codes

Lizenz

Apache License 2.0