netty-resolver-dns-check

io.netty:netty-resolver-dns における3件のDNSキャッシュポイズニングCVE — CVE-2026-45674、CVE-2026-47691、CVE-2026-45673 — のオフラインチェッカーであり、 バージョン番号では答えられない疑問、あなたのアプリケーションは実際にそのリゾルバを使用しているのか? に答えるためのツールです。

Spring WebClient を使用している場合、答えはほぼ間違いなく「はい」です。たとえ pom.xml に netty-resolver-dns がどこにもなく、コード内でそれを呼び出していなくても。

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

これが存在する理由

1. あなたは宣言していない。しかし WebClient はデフォルトでこれを使う。

netty-resolver-dns は4階層の深さでやってきます:

spring-boot-starter-webflux
 └ spring-boot-starter-reactor-netty
    └ reactor-netty-http
       └ reactor-netty-core
          └ netty-resolver-dns        (every link: compile scope)

そしてそれは単にクラスパス上にあるだけではありません。Reactor Netty の HttpClient — Reactor Netty が存在する場合に Spring Boot が WebClient 用に選ぶコネクタ — は、JDK のリゾルバではなく、Netty 自身の DnsAddressResolverGroup でホスト名を解決します:

• 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 リクエストを1回行うと、Netty のリゾルバを通じて実際の DNS クエリを1回 送信しました(WRITE: UDP ... DefaultDnsQuestion(example.com.))。

CVE-2026-45674 と CVE-2026-47691 のアドバイザリは明言しています: 「Netty の DNS リゾルバを使用するあらゆるアプリケーションが影響を受ける。」

2. どの Spring Boot バージョンが影響を受けるデフォルトを同梱しているか

3件の 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 の1行です。より難しい問いは、そのリゾルバが本当に使用されているかどうかです。そこで私たちは実際の Spring Boot 3.5.14 の fat jar を4つ、そして 3.5.16 のものを1つビルドし、グラウンドトゥルース — Netty によって実際に送信された DNS クエリ — を、このツールが jar だけから推測する内容と比較しました:

正直な結果: このツールはオーバーライドがない場合に**「使用中」と確実に判定し、コードと設定からオーバーライドの痕跡を検出します(3件中3件、A での誤検知なし)。しかし B(すべてオーバーライド済み)と D(1つのクライアントがまだデフォルト)を区別することはできません** — 両者のバイトコード上の証拠は同一です。したがってオーバーライドがあっても「影響なし」とは言わず、「手動で確認」と言い、以下に示す1分間のチェックを提供します。

1分間のセルフチェック

1. --logging.level.io.netty.resolver.dns=DEBUG を付けてアプリを起動する
2. 持っている各 WebClient を通じて外向きリクエストを送信させる
3. ログに WRITE: UDP があるか探す — あれば: Netty のリゾルバが使用されている; なければ: そのリクエストはそれを使用していない

「DnsNameResolver がロードされたか?」で判断してはいけません。App B はリゾルバを置き換えても、なおそのクラスをロードしました。デフォルトのリゾルバグループは熱心に(eagerly)構築されるためです。証明になるのはクエリの行だけです。

使用方法

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 は medium(6.8)であり、あなたのリゾルバに到達するには偽装された応答が必要です。アドバイザリごとの深刻度: high が2件(8.7)、medium が1件。
• 環境変数を通じて、またはライブラリ jar の内部で設定されたオーバーライドは、静的スキャンでは見えません。そのような場合、ツールは「使用中」側に倒れます。
• Reactor Netty の HttpClient を直接使用するライブラリ(例えばゲートウェイ)は個別には分析されません — Reactor Netty が存在すれば、デフォルトの経路が仮定されます。
• 4.1 系および 4.2 系以外のバージョンは「判定不能」と報告され、推測はされません。

ルールの出典

GitHub advisory API、2026-09-11 に読み取り:

Spring Boot の表は BootTable.java にあります。ユニットテストがセクション2の3つの記述をそこから再導出するため、表と主張が黙って乖離することはありません。

制御実験

evidence/ には5つのアプリ(A–E)と、アプリごとに WRITE: UDP 行を数える runtime.sh が含まれています。 tools/e2e_real_jars.py は同じ5つの jar に対してこのツールを実行し、各判定をアサートします。 アプリのビルドには Maven 3.6.3 以降が必要です。

終了コード

ライセンス

Apache License 2.0