netty-resolver-dns-check

Offline static checker that inspects packaged Java jars for vulnerable netty-resolver-dns versions and detects whether Spring WebClient actually uses Netty's DNS resolver.

And it is not just on the classpath. Reactor Netty's HttpClient — the connector Spring Boot picks for WebClient whenever Reactor Netty is present — resolves host names with Netty's own DnsAddressResolverGroup, not the JDK resolver:

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

(Same in reactor-netty 1.1.x, 1.2.x, 1.3.x and main.) Spring Boot's connector detection order is reactor > jetty > httpComponents > jdk, so Reactor Netty wins whenever it is there.

We did not stop at reading source. In the controlled experiment below, a default Spring Boot 3.5.14 app making one WebClient request sent one real DNS query through Netty's resolver (WRITE: UDP ... DefaultDnsQuestion(example.com.)).

The advisories for CVE-2026-45674 and CVE-2026-47691 say it plainly: "Any application using Netty's DNS resolver is impacted."

2. Which Spring Boot versions ship an affected default

All three CVEs share the same fix: 4.1.135.Final (4.1 line) / 4.2.15.Final (4.2 line). Read from each spring-boot-dependencies-<v>.pom (<netty.version>), 2026-09-11:

The fixed versions are all on Maven Central. Upgrading works; this tool does not claim otherwise.

3. What static scanning can and cannot tell you

A version number is one line of mvn dependency:tree. The harder question is whether the resolver is really in use. So we built four real Spring Boot 3.5.14 fat jars and one on 3.5.16, and measured the ground truth — DNS queries actually sent by Netty — against what this tool infers from the jar alone:

The honest result: the tool reliably says "in use" when there is no override, and it finds override traces in your code and config (3 of 3, no false positive on A). It cannot tell B (everything overridden) from D (one client still on the default) — their bytecode evidence is identical. So an override never makes it say "not affected"; it says "check manually", and gives you the one-minute check below.

The one-minute self-check

1. Start your app with --logging.level.io.netty.resolver.dns=DEBUG
2. Make it send an outbound request through each WebClient you have
3. Look for WRITE: UDP in the log — present: Netty's resolver is in use; absent: that request did not use it

Do not judge by "was DnsNameResolver loaded?". App B replaced the resolver and still loaded that class, because the default resolver group is built eagerly. Only the query lines are proof.

Usage

It reads what is actually packaged (fat jar BOOT-INF/lib, war WEB-INF/lib, nested jars), not pom.xml — the dependency is transitive, so the pom would tell you it is not there. Presence is decided by the class io/netty/resolver/dns/DnsNameResolver.class, not by version manifests. Override traces are searched only in your own classes and application*.properties/yml (library jars reference these classes themselves).

Output is in Chinese; the verdict lines and CVE ids are what scripts should key on.

What it does not tell you

• Whether an attacker can reach you. CVE-2026-47691, from the advisory: an attacker controlling an authoritative name server for a subdomain can poison the cache for parent domains — so your app has to resolve a name the attacker controls (for example, fetching user-supplied URLs). CVE-2026-45673 is medium (6.8) and needs spoofed responses to reach your resolver. Severity per advisory: two high (8.7), one medium.
• Overrides set through environment variables, or inside a library jar, are invisible to a static scan. The tool errs toward "in use" in those cases.
• Libraries that use Reactor Netty's HttpClient directly (for example a gateway) are not analysed separately — if Reactor Netty is present, the default path is assumed.
• Versions outside the 4.1 and 4.2 lines are reported as "cannot judge", not guessed.

Where the rules come from

GitHub advisory API, read 2026-09-11:

The Spring Boot table is in BootTable.java; a unit test re-derives the three statements in section 2 from it, so the table and the claims cannot drift apart silently.

The controlled experiment

evidence/ contains the five apps (A–E) and runtime.sh, which counts WRITE: UDP lines per app. tools/e2e_real_jars.py runs this tool against the same five jars and asserts each verdict. Building the apps needs Maven 3.6.3 or newer.

Exit codes

License

Apache License 2.0