Nettyに脆弱性、SOCKS通信でドメイン偽装の恐れ

Java製の業務システムやミドルウェアが「SOCKSプロキシ経由」で外部と通信している場合、接続先ドメインを偽装される脆弱性が公表されました。ネットワークフレームワーク Netty の SOCKS クライアント実装に、ヌルバイトとCRLFの検証漏れ（CVE-2026-62380）があります。NVDの評価はCVSS v3.1で7.5（重要）。修正版は 4.1.137.Final と 4.2.17.Final で、すでに公開済みです。

厄介なのは「うちはNettyなんて導入していない」と思っている組織ほど該当しやすい点です。Nettyは単体で導入するものではなく、他の製品の内部で動いているからです。

この記事でわかること

  • Nettyとは何で、どんな製品の中に組み込まれて動いているのか
  • CVE-2026-62380で何ができてしまうのか（ドメイン偽装・認証情報の注入）
  • 自社が該当するかを判定する具体的な手順（Maven/Gradle/JARの調べ方）
  • CVSSスコアが評価機関によって割れている理由と、優先度の付け方

Nettyとは何者か。どこで動いているのか

Nettyとは、Javaでネットワーク通信を行うアプリケーションを作るための、非同期イベント駆動型のフレームワークです。TCP/UDPの低レベルな処理やHTTPなどのプロトコル処理を肩代わりしてくれるため、高性能な通信サーバ・クライアントを実装する際の土台として広く使われています（Netty公式サイト）。

使うのは基本的に開発者です。情シスが製品として購入・導入するものではありません。ここが落とし穴で、Nettyは「みんなが使っているあの製品」の内部に組み込まれて動いています。Netty公式のAdoptersページには、採用プロジェクトとして次のような名前が挙がっています（Netty公式 Adopters）。

  • 検索・分析基盤：Elasticsearch
  • データ処理・分析：Apache Spark、Apache Flink、Trino、Apache Pinot
  • メッセージング：Apache Pulsar、Apache ActiveMQ Artemis
  • データストア／クライアント：Neo4j、Couchbase Java SDK、Lettuce（Redisクライアント）、Infinispan
  • アプリ基盤・RPC：gRPC、Vert.x、Micronaut、Play Framework、Apache Dubbo、Apache NiFi
  • 製品ベンダー：Splunk など

つまり、自社のサーバ資産台帳に「Netty」という行が無くても、ログ基盤・データ分析基盤・社内APIゲートウェイ・業務パッケージのバックエンドとして、実際には動いている可能性が十分にあります。

何が起きたのか（CVE-2026-62380の中身）

問題があるのは Netty 全体ではなく、SOCKSプロキシ通信を扱う io.netty:netty-codec-socks というモジュールです。SOCKS4用の Socks4ClientEncoder とSOCKS5用の Socks5ClientEncoder が、接続先ドメイン名フィールドと認証（ユーザー名／パスワード）フィールドの検証を十分に行っていませんでした。

項目 内容
CVE番号 CVE-2026-62380（CWE-626：Null バイト相互作用エラー）
対象モジュール io.netty:netty-codec-socks
影響バージョン 4.1.136.Final 以前 / 4.2.0.Final 〜 4.2.16.Final
修正版 4.1.137.Final（2026年8月6日公開）／ 4.2.17.Final（2026年8月4日公開）
深刻度 NVD：CVSS v3.1 基本値 7.5（重要）／ 開発元アドバイザリ：CVSS v4.0 6.3（Moderate）
公表の経緯 GitHubアドバイザリ 2026年8月7日 → NVD登録 8月22日 → JVN iPedia登録 8月28日

なぜドメインを偽装できるのか

SOCKS5では接続先ドメインを「長さ1バイト＋文字列」の形で送ります。ここにヌルバイトが混ざっていても弾かれないため、たとえばドメイン名の途中にヌルバイトを埋め込んだ値が送られると、受け取ったプロキシ側の実装次第で解釈が割れます。ヌルバイトで文字列を打ち切る実装なら手前の部分だけが接続先になり、打ち切らない実装なら全体を1つのドメインとして扱います。この解釈のズレが、ドメイン偽装（意図しないホストへの接続）を成立させます。

SOCKS4はさらに素直で、ユーザーID欄がヌル終端文字列です。途中にヌルバイトを埋め込むとパケット内の区切りが二重になり、プロキシから見て構造があいまいになります。認証情報フィールドにはCRLF（改行）も通ってしまうため、認証データの注入も成立します。開発元のアドバイザリは想定される影響として、ドメイン偽装、SOCKS4のユーザーID切り詰め、認証データ注入、プロトコル混乱、そしてドメイン偽装と組み合わせた内部ホストへのSSRFを挙げています。

成立の前提は「攻撃者がドメイン名または認証情報フィールドの値を制御できること」です。外部から受け取ったURLをアプリがプロキシ経由で取りに行く機能（Webhook、URLプレビュー、外部連携の取得処理など）を持っている場合が、最も現実的な経路になります。

自社は影響を受けるのか。判定の手順

判定の軸は「Nettyを使っているか」ではなく「netty-codec-socks が実際に入っているか」です。ここは必ず押さえてください。Nettyを採用している製品でも、SOCKSコーデックまで同梱しているとは限らないからです。

ただし、次の2つの依存経路には注意が必要です。Maven Central上の公式POMで確認したところ、

  • netty-handler-proxy（プロキシ経由の接続を扱うモジュール）は netty-codec-socks に依存しています。プロキシ対応を入れた時点で自動的に付いてきます。
  • まとめ版の netty-all には netty-codec-socks が含まれています。「とりあえず netty-all」で依存を書いている場合は必ず入っています。

確認は、開発チームやベンダーに次の形で依頼するのが早道です。

  • Mavenプロジェクト：mvn dependency:tree -Dincludes=io.netty:netty-codec-socks
  • Gradleプロジェクト：gradlew dependencyInsight --dependency netty-codec-socks --configuration runtimeClasspath
  • 納品されたJAR／WAR：netty-codec-socks-*.jar または netty-all-*.jar というファイルの有無と、そのバージョン番号
  • 商用製品：ベンダーに「CVE-2026-62380の影響有無」を問い合わせる。Nettyは製品に同梱されるコンポーネントなので、ベンダーの修正提供を待つ形になる

そのうえで、SOCKSプロキシを実際に使っているか（Javaの socksProxyHost 設定の有無や、プロキシ設定を伴う外部通信の有無）を確認します。netty-codec-socks が入っていても、SOCKS通信をしていなければ実害の経路はありません。

優先度をどう付けるか。スコアが割れている件

この脆弱性は、評価が分かれています。NVDのCVSS v3.1では7.5（重要）ですが、開発元のGitHubアドバイザリではCVSS v4.0で6.3、深刻度表記は「Moderate」です。またCISAのSSVC評価（2026年8月26日時点）では、悪用の確認は「なし」、自動化可能性も「なし」、技術的影響は「部分的」とされています。

数字が割れるのは、v3.1が完全性への影響を「高」と取るのに対し、v4.0では攻撃の成立に前提条件（攻撃者がフィールドを制御できること）がある点などが加味されるためです。「7.5だから最優先」と機械的に扱うと、実態より過大に見積もることになります。逆に「Moderateだから後回し」と切るのも早計で、外部入力をプロキシ経由の通信に渡す機能があるなら実害の経路は現実にあります。スコアそのものではなく、自社での経路の有無で判断してください。

現場目線の課題

正直なところ、この種の「フレームワークの一部モジュール」の脆弱性は、情シスにとって最も扱いにくい部類です。自分で入れた覚えがないので資産台帳に載らず、載っていないので棚卸しでも引っかかりません。気づけるのは、開発チームが依存ツリーを見たときか、ベンダーが告知したときのどちらかだけです。

そして商用製品に同梱されている場合、こちらにできることは実質「問い合わせて待つ」に限られます。修正版のNettyがリリースされていても、製品ベンダーがそれを取り込んで新バージョンを出すまで手が出せない。この距離感のもどかしさは、依存ライブラリの脆弱性に共通する構造的な問題です。

もう一つ気になるのが、情報が届くまでの時間差です。開発元のアドバイザリ公表が8月7日、NVD登録が8月22日、JVN iPediaへの登録が8月28日。国内の情報源だけを見ていると、3週間ほど遅れて知ることになります。主要な依存ライブラリについては、ベンダーのリリースノートやGitHubのSecurity Advisoriesを直接見る導線を、少数でも持っておく価値があります（参考：Roundcubeに脆弱性10件、CVE採番は8日後）。

情シスはどうすべきか

個別の対応チェックリストを自前で作り込むより、公的機関の指針に沿って「依存コンポーネントを把握する仕組み」を整えるほうが効きます。IPAの中小企業の情報セキュリティ対策ガイドラインは、情報資産の把握と脆弱性対応の運用を体系立てて示しており、規模を問わず出発点として使えます。

今回に限れば、やることは3つに絞れます。開発チームに依存ツリーの確認を依頼すること、商用製品はベンダーに影響有無を問い合わせること、そしてSOCKSプロキシ経由の外部通信を持つ機能を洗い出すこと。ここまでやれば、あとは修正版への更新を待つ／促す段階に入ります。

同じ「見えない依存」の問題は、画像処理ライブラリでも繰り返し起きています。棚卸しの考え方はImageMagickの脆弱性 見えない依存をどう棚卸すかが参考になります。優先度付けの考え方については脆弱性の優先度は組織で変わるもあわせてどうぞ。

まとめ

  • CVE-2026-62380 は、Nettyの netty-codec-socks にあるヌルバイト／CRLF検証漏れ。SOCKS通信でドメイン偽装や認証情報の注入が起こりうる。修正版は 4.1.137.Final / 4.2.17.Final。
  • 「Nettyを導入していない」は判定材料にならない。Elasticsearch・Spark・gRPCなど多くの製品の内部で動いており、netty-all や netty-handler-proxy 経由でSOCKSコーデックが自動的に入る。
  • スコア（7.5と6.3）で決めず、経路の有無で決める。外部入力をプロキシ経由の通信に渡す機能があるかどうかが、実害の分かれ目になる。

出典

タイトルとURLをコピーしました