netty-resolver-dns-check

针对 io.netty:netty-resolver-dns 中三个 DNS 缓存投毒 CVE 的离线检查工具—— CVE-2026-45674、CVE-2026-47691 和 CVE-2026-45673——并回答版本号无法回答的问题： 你的应用是否真的在使用该解析器？

如果你使用 Spring WebClient，答案很可能是肯定的，即使 netty-resolver-dns 并未出现在你的 pom.xml 中，代码中也没有任何地方调用它。

java -jar netty-resolver-dns-check-0.1.0.jar path/to/your-app.jar

为什么需要这个工具

1. 你从未声明它。WebClient 默认使用它。

netty-resolver-dns 经过四层传递引入：

spring-boot-starter-webflux
 └ spring-boot-starter-reactor-netty
    └ reactor-netty-http
       └ reactor-netty-core
          └ netty-resolver-dns        (每一层：compile 作用域)

而且它不仅仅存在于 classpath 上。Reactor Netty 的 HttpClient——只要 Reactor Netty 存在，Spring Boot 就会为 WebClient 选择它作为连接器——使用 Netty 自己的 DnsAddressResolverGroup 解析主机名，而非 JDK 解析器：

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

（在 reactor-netty 1.1.x、1.2.x、1.3.x 和 main 中相同。）Spring Boot 的连接器检测顺序为 reactor > jetty > httpComponents > jdk，因此只要 Reactor Netty 存在，它就会胜出。

我们并未止步于阅读源码。在下面的受控实验中，一个默认的 Spring Boot 3.5.14 应用发起一次 WebClient 请求，通过 Netty 的解析器发送了一次真实的 DNS 查询（WRITE: UDP ... DefaultDnsQuestion(example.com.)）。

CVE-2026-45674 和 CVE-2026-47691 的公告直言不讳： “任何使用 Netty DNS 解析器的应用都会受到影响。”

2. 哪些 Spring Boot 版本默认携带受影响的版本

三个 CVE 共享相同的修复版本：4.1.135.Final（4.1 系列）/ 4.2.15.Final（4.2 系列）。 读取自各 spring-boot-dependencies-<v>.pom（<netty.version>），2026-09-11：

修复版本均已在 Maven Central 上。升级即可生效；本工具并不否认这一点。

3. 静态扫描能告诉你什么，不能告诉你什么

版本号只是 mvn dependency:tree 中的一行。更难的问题是解析器是否真的在使用中。因此我们构建了四个真实的 Spring Boot 3.5.14 fat jar 和一个 3.5.16 的 jar，并测量了真实情况——Netty 实际发送的 DNS 查询——与本工具仅从 jar 推断的结果进行对比：

诚实的结果是：当没有覆盖时，工具可靠地报告 “使用中”，并且能在你的代码和配置中发现覆盖痕迹（3/3，对 A 无误报）。它无法区分 B（全部被覆盖）和 D（一个客户端仍使用默认值）——它们的字节码证据完全相同。因此，覆盖永远不会让它报告“不受影响”；它会报告“请手动检查”，并为你提供下面的一分钟检查方法。

一分钟自检

1. 使用 --logging.level.io.netty.resolver.dns=DEBUG 启动你的应用
2. 让每个 WebClient 各发送一次出站请求
3. 在日志中查找 WRITE: UDP——存在：Netty 的解析器正在使用；不存在：该请求未使用它

不要以“DnsNameResolver 是否被加载？”作为判断依据。应用 B 替换了解析器，但仍然加载了该类，因为默认解析器组是急切构建的。只有查询日志行才是证据。

用法

java -jar netty-resolver-dns-check-0.1.0.jar <directory | jar | war>
java -jar netty-resolver-dns-check-0.1.0.jar --version-of 4.1.132.Final

它读取实际打包的内容（fat jar 的 BOOT-INF/lib、war 的 WEB-INF/lib、嵌套 jar），而非 pom.xml——该依赖是传递性的，因此 pom 会告诉你它不存在。是否存在由类 io/netty/resolver/dns/DnsNameResolver.class 决定，而非版本清单。覆盖痕迹仅在你自己编写的类和 application*.properties/yml 中搜索（库 jar 自身会引用这些类）。

输出为中文；判定行和 CVE id 是脚本应作为依据的内容。

它不会告诉你什么

• 攻击者是否能触及你。 CVE-2026-47691，来自公告：控制某个子域权威名称服务器的攻击者可以污染父域的缓存——因此你的应用必须解析攻击者控制的名称（例如，获取用户提供的 URL）。CVE-2026-45673 为中危（6.8），需要伪造响应才能到达你的解析器。按公告的严重性：两个高危（8.7），一个中危。
• 通过环境变量或库 jar 内部设置的覆盖对静态扫描不可见。在这些情况下，工具倾向于报告“使用中”。
• 直接使用 Reactor Netty 的 HttpClient 的库（例如网关）不会被单独分析——如果 Reactor Netty 存在，则假定使用默认路径。
• 4.1 和 4.2 系列之外的版本报告为“无法判断”，而非猜测。

规则来源

GitHub advisory API，读取于 2026-09-11：

Spring Boot 表位于 BootTable.java 中；一个单元测试会从中重新推导第 2 节中的三条陈述，因此表格与声明不会悄然偏离。

受控实验

evidence/ 包含五个应用（A–E）和 runtime.sh，后者统计每个应用的 WRITE: UDP 行数。 tools/e2e_real_jars.py 对相同的五个 jar 运行本工具，并断言每个判定结果。 构建这些应用需要 Maven 3.6.3 或更高版本。

退出码

许可证

Apache License 2.0