Netty脆弱性まとめ、DNSキャッシュ汚染3件と7月の20件超 4.1.136へ

先に正直なところから書きます。2026年7月28日に米国の脆弱性データベース（NVD）へ新しく載ったCVE-2026-59921は、危険度5.7の中程度で、この記事がもともと扱っていた6月公表の3件（危険度8.7など）より明らかに軽いものです。成立する条件も限られます。「Nettyにまた重大な穴が出た」という話ではありません。

ただ、その1件を調べていくうちに、もっと伝えるべきことが出てきました。Netty（ネティ）の7月のリリースは、20件を超える脆弱性をまとめて塞いだセキュリティ更新です。開発元の告知ページを見ると、4.1.136.Final（7月9日公開）には21件、4.2.16.Final（7月6日公開）には22件の修正が並んでいます。CVE-2026-59921はそのうちの1件にすぎず、しかも重い側ではありません。つまり、6月のDNS修正版（4.1.135.Final／4.2.15.Final）まで上げて安心して止めた組織には、この20件超がまるごと残っています。

Nettyは、Javaで書かれたサーバーが通信を高速にさばくための土台となる部品です。全文検索のElasticsearch、Google発の通信方式gRPC、分散データベースのCassandra、大規模データ処理のSpark、そして国内のJava開発で定番のSpring Bootのリアクティブ機能など、名前が表に出ない場所で動いています。自分で選んだ覚えがなくても、取り込んだ別のソフトの奥に入っている――だからこそ「うちは関係ない」で済ませにくい部品です。6月のDNS3件と7月の追加分を1本に通して整理し、4.1.136 と 4.2.16、どちらに乗せるかを先に示します。

7月に増えた1件は、6月の3件より軽い

まず数字の全体像です。危険度は、深刻さを0〜10で表す国際的な共通スコア「CVSS」です。表の「開発元」はNettyの脆弱性情報を発行しているGitHubが付けた値、「NVD」は米国立標準技術研究所のデータベースが独自に付け直した値です。

この表には、放っておくと誤解を生む食い違いが2つあります。1つめは、6月のDNS2件（CVE-2026-45674とCVE-2026-47691）で開発元の8.7とNVDの10.0が真っ向から違うことです。開発元は「攻撃の難度が高い」という条件を入れて8.7と評価しましたが、NVDはその条件を外し、上限の10.0を付けました。脆弱性スキャナがNVDの値を引くと、同じ穴が最高危険度として報告されます。実務では、後述するようにDNSの偽装は成功に手間と運が要るため、開発元の見立てのほうが実態に近いと考えています。社内報告に10.0が出てきたときに慌てないよう、経緯は知っておく価値があります。なお当サイトの以前の記載ではCVE-2026-47691を8.6としていましたが、一次情報を再確認したところ8.7でした。訂正します。

2つめは、今回のCVE-2026-59921の5.7という数字が報告者本人の見立てとも違うことです。開発元が公開した脆弱性情報（GHSA-gcjf-9mgh-3p7g）の本文には、報告者が自分で計算した「8.1（高）」という値がそのまま載っています。公式の値として採用されたのは開発元の5.7で、NVDもそれを引き写しています。差が出た理由は、報告者が「インターネット越しに攻撃できる」「情報が漏れる」と見たのに対し、開発元は「隣接するネットワークから」「情報漏えいはなし」と判断した点にあります。以下、公式値の5.7を基準に話を進めます。

そして本題です。7月のリリースが塞いだのは4件目の1つだけではありません。開発元の告知に並ぶ21件（4.2系は22件）には、STOMPやSPDY、HAProxy用の部品でメモリを食い尽くされてサービスが止まる不具合、XMLの解析設定が危険なまま初期値になっている問題、証明書の失効確認が正しく行われない問題などが含まれます。個々の内容は後半の表にまとめました。この記事は最新のCVE-2026-59921から順に扱いますが、更新すべき理由としてはこの20件超のほうが重いという前提で読んでください。

4件は、狙う相手も入口も違う

まずはCVE-2026-59921から。ここに手を出せるのは、ファイル添付の画面や取り込み用のAPIを持つサービスに、外から自由にファイルを送り込める立場の人間です。誰でも会員登録できるSaaS、社外から書類を受け取る業務システム、取引先とファイルをやり取りする連携基盤――そうした場所に紛れ込んだ攻撃者が、自分の名前でアカウントを作り、ふつうに使える機能の範囲で仕掛けます。特別な権限は要りません。

改行文字をひとつ紛れ込ませるだけで済みます。アップロードするファイルの「名前」に改行を仕込み、サービスが内部で別のサーバーへ転送するときの伝票に、本来なかった行を書き足させることが可能になります。たとえば「これは画像です」と書かれた伝票を「これはWebページです」に書き換えると、受け取った側は画像として保管したはずのファイルをページとして表示してしまいます。そこに仕込まれた命令文が、あとから見に来た利用者のブラウザで動く、という筋書きです。ファイル名という、誰も危険だと思っていない場所が入口になるのが厄介な点です。

身に覚えのない内容を見せられ、ログイン状態を盗まれる――これがサービスを使う側に起きうることです。運営する側が負うのは別の傷です。自社のドメインから怪しい内容が配信されたという事実を背負い、原因の特定に時間を取られます。一方、6月のDNS3件はまったく別の相手が狙う穴で、こちらは通信そのものを偽のサーバーへ向けさせるものです。狙うのは企業間の通信に割り込んで認証情報を抜きたい相手で、成功すれば被害はずっと静かに、ずっと広く進みます。同じ製品の脆弱性でも、確認すべき場所と急ぎ方が違うわけです。

4.1.136 と 4.2.16、どちらに乗せるか

読者がいちばん必要としているのはこの一覧だと思います。6月分と7月分を通して並べました。系列（4.1系か4.2系か）を確かめてから、自分の番号の行を見てください。

4.2系のほうが1件多いのは、4.2系だけが持つHTTP/3用の部品（netty-codec-http3）の修正（CVE-2026-56816）が加わるためです。4.1系と4.2系は別々に保守されている系列で、番号の大小では新旧を判断できません。4.1.136.Finalと4.2.16.Finalは、どちらも同じ7月分の修正を含む到達点です。

上位ソフトを最新にしても、7月分は塞がらない

更新の落とし穴はここにあります。多くの現場ではNettyを直接指定せず、Spring BootやgRPCが決めたバージョンをそのまま使います。そこで各ソフトの最新版が実際に指定しているNettyの番号を、公開されている依存定義ファイル（BOM）で1つずつ確かめました。結果は次のとおりで、どれも7月分の修正を含んでいません。

確認に使ったのは配布元に置かれている定義ファイルそのものです（Spring Boot 4.1.0の依存定義、gRPC-Java 1.83.0の依存定義）。とくに注意したいのはSpring Boot 3.4系で、指定が4.1.130.Finalのままなので、6月のDNS3件も塞がっていません。上位ソフトの更新を待つ姿勢だけでは追いつかないため、次の「自力で上げる」手順が必要になります。

7月に加わった1件をくわしく見る

CVE-2026-59921: 送るファイル名に改行を混ぜられ、伝票に行が足される

Nettyには、ファイルを含むデータを組み立てて別のサーバーへ送り出す部品（HttpPostRequestEncoder）があります。この部品は、送るデータの1つ1つに「これは何という名前のファイルか」を書いた小さな伝票（Content-Disposition）を付けます。伝票の各行は改行で区切られる決まりです。ところがCVE-2026-59921では、ファイル名をこの伝票へそのまま貼り付けていたため、ファイル名の中に改行が入っていると行が増えてしまう状態でした。分類上は「改行文字の無害化漏れ（CWE-93）」です。

開発元の脆弱性情報には、報告者が実際に動かした検証コードと出力がそのまま載っています。ファイル名を「innocent.txt"（改行）Content-Type: text/html（改行）X-Injected: true」として送ると、組み立てられたデータの中にContent-Type: text/htmlという行とX-Injected: trueという行が実際に追加されました。検証はNetty 4.2.12.Finalで行われています。受け取り側が最初に現れた種類の指定を信じる作りだと、画像として送ったはずのファイルがWebページとして扱われ、埋め込まれた命令文が動く余地が生まれます。ほかにも、データの区切り線を偽造して別のフォーム項目を後から差し込む手口が示されています。

影響を受けるのは、Nettyを使って自分から外へファイルを送っている構成です。ここを取り違えないでください。よくある「利用者がアップロードしたファイルを自分のサーバーで受け取る」処理は別の部品が担当しており、今回の対象ではありません。当てはまるのは、受け取ったファイルを名前ごと別のサービスへ中継するアップロードの窓口、外から来た値を組み立てて社内APIへ渡すゲートウェイ、サービス間でファイルを受け渡すマイクロサービス、そして利用者の入力からファイル名を作る自動テストの仕組みなどです。開発元が影響ありとしている部品はio.netty:netty-codec-httpで、対象は4.1.136.Finalより前のすべて、および4.2.0.Finalから4.2.15.Finalまでです。

修正の中身も、公開されているソースで確認しました。4.1.136.Finalでは、ファイル名を設定する入口（setFilename）が、これまでの「空でないかだけ見る」処理からFileUploadUtil.validateFileNameForMultiPartという検査に置き換わっています。この検査は改行だけを弾くのではなく、制御文字すべて、削除文字、二重引用符（"）、円記号（\）を含むファイル名をエラーとして拒否します。報告者が提案していた対策より厳しめの作りです。

この厳しさは、更新のときに1つ注意点を生みます。ファイル名に引用符や円記号が入る運用をしているアプリは、更新後にIllegalArgumentExceptionで処理が止まる可能性があります。Windowsのパス（C:\dir\file.txt）をそのまま名前として渡している箇所などが引っかかります。更新前に、ファイル名を作っている場所を一度見ておくと事故を避けられます。なお項目名（フィールド名）のほうは以前から改行やタブを除去する処理が入っており、4.1.135.Finalと4.1.136.Finalで変わっていません。実際に穴だったのはファイル名の側です。

報告者は、脆弱性情報の記載によればPayPalのサイバーセキュリティチームのYu Bao氏です。開発元が脆弱性情報を公開したのは7月22日、NVDに載ったのは7月28日で、修正版が出た7月上旬より後でした。修正が先、番号が後という順番だったため、7月に更新を済ませた組織はすでに塞がっています。

6月に公表されたDNSの3件（通信先を偽装される穴）

ここからは6月に公表された3件です。いずれも、インターネットの住所案内である「DNS」の扱いに関わります。DNSとは、人が読む名前（例: example.com）を、機械が通信に使う数字の住所（IPアドレス）へ変換する仕組みのことです。この変換結果を偽物にすり替えられると、通信そのものが攻撃者の手元へ誘導されます。総称して「DNSキャッシュ汚染（DNSキャッシュポイズニング）」と呼びます。3件は4.1.135.Final／4.2.15.Finalで塞がれており、7月の修正版にも当然含まれます。

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

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

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

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

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

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

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

同じ4.1.136／4.2.16で塞がれる、そのほかの脆弱性

7月の修正版が含む脆弱性のうち、危険度が高めに評価されているものを抜き出しました。区分は開発元（GitHub）が付けたものです。表に入りきらないものも含め、開発元の告知には4.1系で21件、4.2系で22件が並んでおり、そのうち2件はCVE番号の割り当て前で「CVE-2026-XXXXX」と表記されています。

並べてみると、7月分の多くは「大量に送りつけてサーバーを止める」タイプで、今回の追加分であるCVE-2026-59921より重い評価のものが複数あることがわかります。処理を止められる系の脆弱性は、外部からの通信を受ける入口ほど効いてきます。Webサーバー側でも同じ構図が繰り返されていて、少ない通信量でCPUを使い切らせるApache HTTP/2の処理停止の脆弱性や、Java系の通信基盤という同じ系譜にあるApache MINAの脆弱性と読み比べると、どこに注意が要るかが見えてきます。サーバー製品側の同種の話はApache Tomcatの脆弱性まとめにも整理しています。

自分のシステムが使っているかを確かめる手順

Nettyは「使っている自覚がない」部品の代表です。まずは実際に入っているバージョンを出してください。Mavenを使っているなら次の1行で、間接的に取り込まれているものまで含めて一覧になります。-Dincludesにグループ名だけを渡す書き方は公式ドキュメントで認められています。

mvn dependency:tree -Dincludes=io.netty

Gradleの場合は、実行時に使われる組み合わせを指定して出すのが確実です。さらに「どのライブラリが古いNettyを連れてきているのか」を1件だけ追いたいときはdependencyInsightを使います。この書き方もGradle公式ドキュメントのとおりです。

./gradlew dependencies --configuration runtimeClasspath

./gradlew dependencyInsight \
  --dependency io.netty:netty-codec-http \
  --configuration runtimeClasspath

出てきた一覧の、どの部品を見るかで判断が変わります。今回のCVE-2026-59921に関わるのはnetty-codec-http、6月のDNS3件はnetty-resolver-dns、7月分のサービス停止系はnetty-codec-stompやnetty-codec-haproxy、netty-codec-xmlなどです。ただ実務では部品ごとに悩むより、io.nettyの行に出てくる番号がすべて4.1.136.Final以上（または4.2.16.Final以上）になっているかだけを見たほうが早く済みます。依存の棚卸しを継続的に回す考え方はOSSサプライチェーンの点検の仕組みにまとめてあり、Javaの依存にも同じやり方が使えます。

依存の奥にある古いNettyを、自力で上げる

先の表のとおり、上位ソフトの最新版を待っても7月分は塞がりません。直接指定していない場合でも、ビルド設定でバージョンを上書きできます。Mavenでは、Netty自身が公開しているまとめ定義（netty-bom）を先に読み込ませるのが手堅い方法です。4.1.136.Finalと4.2.16.Finalのどちらも配布されています。

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>io.netty</groupId>
      <artifactId>netty-bom</artifactId>
      <version>4.1.136.Final</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

Gradleなら、同じまとめ定義をプラットフォームとして読み込みます。個別に無理やり寄せたいときはresolutionStrategyで強制する手もありますが、まとめ定義のほうが部品間のバージョンずれを避けられます。

dependencies {
  implementation platform('io.netty:netty-bom:4.1.136.Final')
}

Spring Bootを使っている場合は、もっと素直な方法があります。Spring Bootは自分の依存定義の中でnetty.versionという値を使ってNettyのまとめ定義を読み込んでいるため、この値だけを上書きすれば全体が入れ替わります。Mavenならpom.xmlのプロパティに、Gradleなら公式プラグインの説明にあるとおりextで指定します。

<!-- Maven（Spring Boot 4.x 系＝Netty 4.2系の場合） -->
<properties>
  <netty.version>4.2.16.Final</netty.version>
</properties>

// Gradle（Groovy）
ext['netty.version'] = '4.2.16.Final'

上書きするときは系列を間違えないでください。Spring Boot 3.5系は4.1系（4.1.135.Final）を、Spring Boot 4.x系は4.2系（4.2.15.Final）を指定しています。3.5系なら4.1.136.Final、4.x系なら4.2.16.Finalが上げ先です。もう1つ、Spring Boot公式は「各リリースは特定の組み合わせで検証されているため、バージョンの上書きは互換性の問題を起こす可能性がある」と注意しています。同じ系列内の小さな更新なので大きな非互換は起きにくいものの、上書き後は通信まわりの試験を通してから本番へ出してください。前述のファイル名検査が厳しくなった件も、ここで引っかかる可能性があります。

どれくらい急ぐべきか、国内の情報はどうなっているか

悪用の兆しを示す指標を見ておきます。米政府CISAが公開している「実際に攻撃に使われている脆弱性の一覧」（KEV）は、2026年7月27日版で1,655件を収録していますが、Nettyの4件はいずれも入っていません。悪用の確率を推定する指標EPSSでは、6月のDNS3件が0.2〜0.3%程度（全体の下位2割前後）と低い値にとどまり、今回のCVE-2026-59921はまだ算出されていません。CISAの別の判定（SSVC）でも、CVE-2026-45674は「悪用の確認なし・自動化不可」とされています。KEVの収録状況をまとめて追う方法はCISA KEVダッシュボードの記事で解説しています。

国内の登録状況は、6月分と7月分でくっきり差が出ています。IPAが運営する脆弱性データベースJVN iPediaには、6月のDNS3件がすべて日本語で登録済みです（JVNDB-2026-019795＝CVE-2026-45674、JVNDB-2026-019796＝CVE-2026-45673、JVNDB-2026-019792＝CVE-2026-47691。いずれも6月15日登録）。一方、7月分はCVE-2026-44891など3件が7月24日に登録されただけで、CVE-2026-59921は7月29日時点で未登録です。JPCERT/CCやIPAからの注意喚起も出ていません。日本語で7月分をまとめた情報も見つかりませんでした。

よくある質問

Q. 6月に4.1.135.Finalへ上げました。もう対応は終わりですか？

終わっていません。4.1.135.FinalはDNSの3件を塞いだ版で、7月の21件はその後の4.1.136.Finalで塞がれています。今回公表されたCVE-2026-59921もこの21件に含まれます。4.1.136.Finalへもう一段上げてください。

Q. 自分のアプリがNettyを使っているか分かりません。どう確認しますか？

Mavenならmvn dependency:tree -Dincludes=io.netty、Gradleなら./gradlew dependencies --configuration runtimeClasspathを実行してください。直接・間接の両方が一覧で出ます。io.nettyの行があれば使っています。どのライブラリが古い版を連れてきているかまで追うなら./gradlew dependencyInsight --dependency io.netty:netty-codec-http --configuration runtimeClasspathが便利です。

Q. ファイルのアップロードを受け付けるサーバーです。CVE-2026-59921の対象ですか？

受け取るだけなら対象外です。今回の穴は、Nettyを使って自分から外へファイルを送り出す処理にあります。受け取ったファイルを名前ごと別のサービスへ中継している場合や、外から来た値でファイル名を組み立てて社内APIへ渡している場合は対象になり得ます。判断に迷うなら、コードの中でHttpPostRequestEncoderを使っているかを検索してみてください。

Q. Spring Bootを使っています。Spring Bootを最新にすれば済みますか？

済みません。2026年7月29日時点の最新であるSpring Boot 4.1.0が指定しているNettyは4.2.15.Finalで、7月分の修正を含みません。netty.versionプロパティを4.2.16.Final（3.5系なら4.1.136.Final）に上書きしてください。上書き後は通信まわりの試験を通してから本番へ出すのが安全です。

Q. 更新するとファイル名でエラーが出るようになると聞きました。本当ですか？

起こり得ます。4.1.136.Final／4.2.16.Finalではファイル名の検査が追加され、制御文字・削除文字・二重引用符・円記号を含む名前がIllegalArgumentExceptionで拒否されます。Windowsのパスをそのままファイル名として渡している箇所などが引っかかります。更新前に、ファイル名を生成している場所を確認しておくと安全です。

Q. スキャナが危険度10.0と報告してきました。すぐ止めるべきですか？

その10.0はNVDが6月のDNS2件（CVE-2026-45674・CVE-2026-47691）に独自に付けた値です。開発元は同じ穴を8.7と評価しており、CISAの判定でも悪用の確認はありません。DNSの偽装は成功にタイミングと試行が要るため、サービスを止めるほどの緊急性は現時点ではないと考えています。ただし修正版は出ているので、計画的な更新は必要です。

更新履歴

参照元

• ▸ Netty公式アドバイザリ - GHSA-gcjf-9mgh-3p7g（CVE-2026-59921 / ファイル名によるCRLF注入）
• ▸ NVD - CVE-2026-59921（CVSS 5.7 / CWE-93 / 2026年7月28日公開）
• ▸ Netty - 4.1.136.Final リリース告知（セキュリティ修正21件の一覧）
• ▸ Netty - 4.2.16.Final リリース告知（セキュリティ修正22件の一覧）
• ▸ GitHub - netty-4.1.136.Final リリースページ（変更一覧・ソース）
• ▸ Netty公式アドバイザリ - GHSA-676x-f7gg-47vc（CVE-2026-45674 / CNAMEの管轄未確認）
• ▸ NVD - CVE-2026-45674（開発元8.7 / NVD 10.0 / DNSキャッシュ汚染）
• ▸ NVD - CVE-2026-47691（開発元8.7 / NVD 10.0 / NSレコードの管轄未確認）
• ▸ NVD - CVE-2026-45673（CVSS 6.8 / 問い合わせ番号の予測しやすさ）
• ▸ JVN iPedia - JVNDB-2026-019795（CVE-2026-45674の日本語登録）
• ▸ JVN iPedia - JVNDB-2026-024925（7月分で登録済みのCVE-2026-44891）
• ▸ CISA - 悪用が確認された脆弱性カタログ（KEV / 2026年7月27日版で未収録）
• ▸ FIRST - EPSS（悪用確率の推定指標）
• ▸ GitLab Advisory - io.netty/netty-resolver-dns（影響バージョン一覧）
• ▸ Apache Maven - 依存ツリーの絞り込み方（-Dincludes の書式）
• ▸ Gradle - 依存関係の確認方法（dependencies / dependencyInsight）
• ▸ Spring Boot - 管理バージョンの上書き方法（netty.version の指定）