Netty に通信先を偽装される脆弱性3件、最新版へ更新を CVE-2026-45674

企業のサーバーの裏側で広く使われている通信基盤Netty（ネティ）に、アプリが通信する相手を攻撃者の用意した別のサーバーへすり替えられる脆弱性が見つかり、修正版が公開されました。Nettyは、Javaで書かれたサーバーが高速に通信を処理するための土台となる部品で、検索エンジン、データベース、各種APIの中継役など、名前が表に出ない場所で動いています。自分で使った覚えがなくても、取り込んでいる別のソフトの内部で動いている可能性が高いのが特徴です。

中心となるのはCVE-2026-45674で、Nettyが「この名前のサーバーはどこにあるか」を調べる住所案内（DNS）の応答を、正しい相手からのものか確かめずにそのまま信じてしまう穴です。これを突かれると、本来つなぐはずだったサーバーの住所が偽の住所に書き換えられ、気づかないうちに攻撃者のサーバーへ接続させられます。同じ時期に、住所案内の処理に関わるCVE-2026-45673とCVE-2026-47691もまとめて公表されました。

3件はいずれも修正版のNetty 4.1.135.Final（および新系列の4.2.15.Final）で塞がれています。今のところ実際の攻撃に使われた報告はなく、悪用には後述のとおり一定の条件と手間が必要なため、過度に慌てる必要はありません。ただしNettyを取り込んでいるソフトの数が極めて多いため、自社の依存関係を確認して更新を済ませておくのが安全です。

Nettyとは何で、なぜ自分にも関係するのか

Nettyは、Java（業務システムで広く使われるプログラミング言語）のサーバーが、大量の通信を効率よくさばくための土台となる部品です。サーバー同士がデータをやり取りする「ネットワーク処理」を一手に引き受ける役割で、性能と安定性が求められる場面で定番として使われています。表向きのアプリ名としては出てきませんが、その下で静かに通信を支えているのがNettyです。

やっかいなのは、自分のアプリが直接Nettyを呼んでいなくても、取り込んでいる別のソフトが内部でNettyを使っているケースが非常に多いことです。これを「間接依存」と呼びます。たとえば全文検索のElasticsearchやOpenSearch、Googleが主導する通信方式gRPC、分散データベースのCassandra、大規模データ処理のSparkなど、企業のシステムでおなじみの製品の多くが内部でNettyを使っています。そのため「うちはNettyなんて使っていない」と思っていても、依存関係をたどると奥のほうで動いていることが珍しくありません。

とりわけ影響が出やすいのは、Nettyの「住所案内（DNS）を自前で引く機能」を使っているケースです。後述するように、今回の穴はこのDNS解決の処理に集中しているため、外部のサーバーへ頻繁に接続しにいくような作りのシステムほど、確認の優先度が上がります。

3つの脆弱性の概要

3件とも、Nettyがインターネットの住所案内である「DNS」をどう扱うかに関わる穴です。DNSとは、人が読む名前（例: example.com）を、機械が通信に使う数字の住所（IPアドレス）に変換する仕組みのことです。この変換結果を偽物にすり替えられると、通信そのものが攻撃者の手元へ誘導されます。危険度の数字は、深刻さを0〜10で表す国際的な共通スコア「CVSS」です。

中心はCVE-2026-45674とCVE-2026-47691で、どちらもDNS応答の中身を正しい相手からのものか確かめないために、偽の住所を信じ込まされる穴です。CVE-2026-45673は単体で乗っ取るタイプではなく、偽の応答を攻撃者が「当てやすくする」補助的な穴で、ほかの2件と組み合わさると成功率を押し上げます。これらを総称して「DNSキャッシュ汚染（DNSキャッシュポイズニング）」と呼びます。

偽の道案内に従った先で、何が起きるのか

「DNSキャッシュ汚染」という言葉だけでは自分の損害が見えにくいので、これが成立したとき現実に何が起きるかを攻撃者の側から見ておきます。要は、目的地までの道案内の看板を一枚すり替えられる攻撃です。看板を信じて進んだ先に待っているのは、本物そっくりに作られた攻撃者のサーバーです。

狙ってくるのは、企業間の通信に割り込んで決済情報や認証トークンを抜く詐欺グループ、取引先になりすまして偽の指示を流し込む産業スパイ、盗んだ通信内容を素材にさらなる侵入口を探すランサムウェア集団です。すり替えられた先で持ち去られるのは、サーバー同士がやり取りするログイン用のアクセストークン、APIの秘密鍵、決済や個人情報を含む通信の中身、そして相手サーバーになりすますための証明書情報です。CVE-2026-45674で住所案内を書き換えられた瞬間、本物のサーバーへ送ったつもりの機密情報が、まるごと攻撃者のサーバーへ届いてしまいます。

この攻撃の怖さは、利用者にもアプリにも異常がほとんど見えないことです。画面はいつもどおり動き、通信もエラーを出しません。ただ、その通信が経由している相手だけが入れ替わっています。サーバー同士の信頼を土台にした自動連携ほど被害が静かに広がりやすく、気づいたときには取引データや認証情報が長期間にわたって筒抜けだった、という事態になりかねません。

そして被害の責任は、Nettyの開発者ではなく、それを組み込んだサービスの運営会社に返ってきます。CVSS 8.7という数字は通信が乗っ取られる技術的な深刻さを示すだけで、その先で起きる情報漏えいの後始末や信用の回復にかかるコストは含まれていません。悪用に手間がかかるとはいえ、修正版が出ている今、依存関係を確認して更新できるかどうかが分かれ目になります。

3件をくわしく見る

CVE-2026-45674: 別名情報の出所を確かめずに信じてしまう

DNSの応答には、「この名前は別の名前の別名です」と案内する情報（CNAMEレコード）が含まれることがあります。本来は、その案内が「問い合わせた相手が答える権限を持つ範囲」のものかを確認しなければなりません。ところがCVE-2026-45674では、Nettyがこの権限の範囲（専門用語で「bailiwick＝管轄」と呼びます）を確認せず、応答に入っていた別名情報を無条件に受け入れて記憶してしまいます。

これを突かれると、通信経路を直接覗ける立場になくても（こうした立場を「経路外の攻撃者」と呼びます）、偽の別名情報を紛れ込ませることで、本来とは違うサーバーの住所を信じ込ませられます。結果として、以後その名前への通信が攻撃者のサーバーへ誘導されます。危険度はCVSS 8.7。情報の盗み見や改ざんにつながる一方、サービスを停止させるタイプではないため、可用性への影響は「なし」と評価されています。

CVE-2026-47691: 案内役サーバーの情報も同じく無確認

CVE-2026-47691は、CVE-2026-45674と同じ「出所の無確認」の問題が、別の種類のDNS情報（その名前の案内役サーバーを指し示すNSレコード）でも起きていたものです。攻撃者は案内役そのものを偽のサーバーに差し替えられるため、以降の問い合わせがまるごと攻撃者の支配下に置かれます。危険度はCVSS 8.6で、こちらも修正は4.1.135.Final系で行われています。

CVE-2026-45673: 偽の応答を「当てやすく」する補助の穴

CVE-2026-45673は、それ単体でサーバーを乗っ取るタイプではありません。DNSの問い合わせには、偽の応答を弾くために「問い合わせごとの番号」と「送信元の入口番号（ポート）」がランダムに割り振られます。この穴では、その番号の作り方が予測されやすく、入口番号も固定されがちだったため、攻撃者が偽の応答を「正解」として当てる確率が大きく上がります。前の2件と組み合わさることで、汚染の成功率を底上げする役割を果たします。

どれくらい危険か（慌てる必要はないが放置もできない理由）

今回の3件は、いますぐパニックになる種類のものではありません。最も重いCVE-2026-45674でも、危険度の評価には「攻撃の難度が高い」という条件が含まれています。DNSキャッシュ汚染は、偽の応答を本物より先に、しかも問い合わせ番号などを当てた状態で滑り込ませる必要があり、成功には相応のタイミングと試行が要ります。実際にこの3件が攻撃に使われたという報告も、現時点ではありません。

一方で、放置していい話でもありません。第一に、Nettyは推移的依存であまりに多くのシステムに潜んでおり、「自分は無関係」と思っている組織ほど気づかないまま影響範囲に入っています。第二に、3件が同時に公表されたことで、攻撃者から見れば「番号を当てやすくする穴」と「出所を確かめない穴」が手元にそろった状態です。組み合わせは成功率を押し上げます。第三に、修正の公開は穴の場所を明らかにするため、時間が経つほど悪用の研究が進みます。慌てる必要はないが、更新を予定に入れて着実に潰しておくべき――というのが、この3件の正確な温度感です。

自分のアプリは影響を受けるか（確認手順とバージョン早見表）

いま使っているNettyのバージョンは、Mavenを使っているならmvn dependency:tree -Dincludes=io.netty、Gradleならgradle dependenciesで確認できます。間接依存も含めて、どのバージョンが入っているかが一覧で出ます。今回の穴が関わるのは特にDNS解決の部品（netty-resolver-dns）です。下の表で自分の番号を照合してください。

間接依存で古いNettyが入っている場合は、それを呼んでいる親の製品（ElasticsearchやgRPCなど）の更新が必要になることもあります。まずはmvn dependency:treeで「どの製品が古いNettyを連れてきているのか」を把握しておくと段取りが楽になります。npmやPythonの依存を点検するOSSの脆弱性チェックの仕組みと同じ発想で、Javaの依存についても「どのバージョンが入っているか」を定期的に棚卸しする習慣が、こうした見落としを防ぎます。

いま取るべき対応

最も確実な対策は、Nettyを4.1.135.Final（新系列なら4.2.15.Final）以降へ更新することです。直接依存していればビルド設定（pom.xmlやbuild.gradle）のバージョン指定を上げ、間接依存の場合は親の製品の更新を待つか、ビルドツールのバージョン強制機能（MavenのdependencyManagementやGradleの制約）で安全なバージョンに寄せます。

すぐに更新できない事情がある場合の当座の手当てとしては、社内のシステムが使うDNSを、検証機能（DNSSECなど）を備えた信頼できる経路に限定する、外部のDNSサーバーへ直接問い合わせに行く構成を見直す、といった対策が併用できます。ただしこれらは時間稼ぎであり、根本対策はあくまで本体の更新です。悪用に手間がかかる今のうちに、依存関係の棚卸しと更新の計画を進めておくのが、静かに広がるタイプの被害を防ぐ最善手です。

参照元

• ▸ Netty公式アドバイザリ - GHSA-676x-f7gg-47vc（CVE-2026-45674 / CNAMEの管轄未確認）
• ▸ NVD - CVE-2026-45674（CVSS 8.7 / DNSキャッシュ汚染）
• ▸ NVD - CVE-2026-47691（CVSS 8.6 / NSレコードの管轄未確認）
• ▸ NVD - CVE-2026-45673（問い合わせ番号の予測しやすさ）
• ▸ Netty - リリースノート（4.1.135.Final）
• ▸ GitLab Advisory - io.netty/netty-resolver-dns（影響バージョン一覧）