.NET 緊急更新（2026年10月）｜影響条件と再配布の判断

はじめに

2026 年 10 月 25 日（米国時間）、Microsoft は .NET 8、.NET 9、.NET 10 と .NET 11 Release Candidate 3 に向けて、定例外（OOB）のセキュリティ更新を公開しました。新たに Brotli デコーダーの範囲外書き込み（CVE-2026-111497）と Linux tarball の所有権の問題（CVE-2026-114148）が修正され、10 月 13 日の定例更新で修正が十分でなかった CVE-2026-70197 と CVE-2026-102870 も再修正されています。

4 件の CVE は、影響を受ける環境も対応方法も異なります。Brotli の問題は既定で無効な展開処理を使っているかどうかで影響が変わり、tarball の問題は修正版を上書き展開しても解消しません。さらに、self-contained やコンテナで配布したアプリケーションは、ホストの Runtime を更新しても修正が反映されません。本記事は、2026 年 10 月 26 日時点で確認した Microsoft の公開情報に基づいて整理したもので、筆者自身による実機での検証は行っていません。

結論として、各系列の更新先は 8.0.33、9.0.22、10.0.14、11.0.0-rc.3 です。影響の有無はバージョンだけでなく、攻撃者が制御できる Brotli データを実際に展開しているかで判断します。self-contained、コンテナ、NativeAOT のアプリケーションは再発行と再配布が必要で、Blazor WebAssembly の NuGet パッケージは Runtime とは別に更新する必要があります。

.NET 緊急更新（2026 年 10 月）の CVE と修正版

今回の OOB 更新には、新たに公表された 2 件と、10 月 13 日に公表済みの 2 件の再修正が含まれます。10 月 13 日の更新を適用済みの環境でも、今回の修正版の適用が必要です。

今回追加の 2 件と再修正の 2 件

CVSS は各アドバイザリの記載です。

4 件の性質の違いは次のとおりです。

CVE-2026-111497（Brotli）

不正な Brotli 圧縮データを展開するとメモリが破壊され、情報漏えい、サービス拒否、権限昇格につながる可能性があります。アドバイザリは認証不要の攻撃者による悪用の可能性を示す一方、攻撃の複雑さは High と評価しています。成立には、攻撃者が制御できるデータがアプリケーションの展開処理へ到達することが前提です。

CVE-2026-114148（Linux tarball）

対象の tarball から展開したファイルの所有者が不適切になり、ローカルアカウントが上位の権限で動くアプリケーションのファイルを改ざんできる可能性がある問題です。攻撃元区分はローカルで、ネットワーク経由のリモートコード実行とは性質が異なります。

CVE-2026-70197（Windows のソケット）

Windows の System.Net.Sockets における SocketAsyncEventArgs のメモリ破壊で、アドバイザリの区分はリモートコード実行です。10 月 13 日の更新では修正が十分でなかったため、同じ CVE 番号のまま修正済みのパッケージが再公開されました。.NET 8 では、影響を受ける Windows 向けパッケージに CoreCLR と Mono の両方の runtime pack が含まれます。

CVE-2026-102870（Blazor デバッガー）

Blazor WebAssembly のデバッグプロキシーが式評価のために C# のソースを生成する際、デバッグ対象のアプリケーションに由来する値を適切にエスケープしない問題です。開発者がデバッグ中に、攻撃者が制御するデータを含む式を評価すると、開発者の端末でコードが実行される可能性があります。通常の本番 Web アプリケーションの処理経路で成立する問題ではありません。

系列別の修正版と SDK のバージョン

Runtime と SDK は別のバージョン番号を持ちます。SDK には対応する Runtime が含まれるため、下表の SDK を導入すれば同じ行の Runtime も導入されます。

.NET 11 RC3 は正式版ではなくプレリリースです。RC2 を利用している環境は、RC3 へ更新することで今回の修正を取り込めます。.NET Framework は今回の対象外です。Windows では、.NET 10.0.14 が Microsoft Update でクライアント OS 向けに、WSUS と Microsoft Update カタログで Windows Server 向けに提供されると、Microsoft サポートの更新情報で案内されています。

この表は Runtime と SDK の修正版を示すもので、Runtime の更新だけで 4 件すべてが解消するわけではありません。CVE-2026-114148 は導入元の tarball によって対応が異なり、CVE-2026-102870 は NuGet パッケージの更新が別途必要です。それぞれの対応は後述します。

なお、Microsoft のリリース一覧では、.NET 8 と .NET 9 のサポート終了日はいずれも 2026 年 11 月 10 日です。今回の OOB 更新の適用と、サポートが継続する系列への移行計画は別の対応です。8.0.33 / 9.0.22 を適用したうえで、.NET 10 などへの移行計画を別途進めることをおすすめします。

Brotli（CVE-2026-111497）の影響条件と暫定対策

Brotli の問題は、圧縮ではなく展開（デコード）の処理で発生します。ASP.NET Core のリクエスト展開と HttpClient の自動応答展開は既定で無効のため、影響を受けるバージョンを使っているだけでは、外部からの攻撃が成立するとは判断できません。

参考: Microsoft Security Advisory CVE-2026-111497
“An application is not exposed merely because an affected .NET package is installed.”
（影響を受ける .NET パッケージが導入されているだけで、アプリケーションが攻撃にさらされるわけではない）
https://github.com/dotnet/runtime/security/advisories/GHSA-p3jp-9v83-76w9

Brotli データが展開される 3 つの経路

アドバイザリが挙げる展開経路は次の 3 つです。

ASP.NET Core のリクエスト展開

リクエスト展開ミドルウェアを有効にし、br の展開を受け付けている場合です。クライアントが送るリクエスト本文が展開されるため、外部に公開した API では、攻撃者が入力を制御できる経路になります。

HttpClient の自動応答展開

HttpClientHandler.AutomaticDecompression または SocketsHttpHandler.AutomaticDecompression に DecompressionMethods.Brotli か DecompressionMethods.All を設定している場合です。接続先のサーバーが応答を制御できるため、ユーザーが指定した URL や外部の Webhook 先へ接続する処理では、優先度が上がります（編集上の整理）。

System.IO.Compression の明示的な呼び出し

アプリケーションのコードで BrotliStream や BrotliDecoder を使って展開している場合です。アップロードされたファイル、メッセージキュー、外部ストレージなど、入力元が外部であれば対象になります。この経路は既定設定の有無に関係しません。

自社環境の影響を判断する確認ポイント

影響の判断では、アプリケーションごとに次の 4 点を確認することをおすすめします。

1. 設定: AddRequestDecompression の呼び出しや、AutomaticDecompression の設定がコードや構成にあるか
2. コード: BrotliStream や BrotliDecoder を使う処理があるか（利用しているライブラリー内部の処理を含む）
3. 入力元: 展開するデータを、外部の利用者や接続先が制御できるか
4. 到達経路: リバースプロキシーや API ゲートウェイを経由して、圧縮されたままのデータがアプリケーションまで届くか

これらに該当しない場合でも、修正版の適用は必要です。確認結果は適用の優先度を決めるための材料であり、更新を省略する根拠にはなりません。なお、Node.js も同じ CVE 番号で Brotli の修正を公開していますが、展開経路や更新方法は .NET と異なります。Node.js 側の影響条件は『Node.js 脆弱性（2026年10月）｜影響確認と更新判断』で解説しています。OS の brotli パッケージや、Brotli を同梱する他の製品は、.NET の更新では修正されないため、それぞれの提供元の情報を確認してください（編集上の整理）。

更新まで Brotli 展開を無効化する場合

アドバイザリは、更新を展開するまでの間、攻撃者が制御する Brotli データを展開しないよう求めています。そのうえで、すでに展開機能を使っている場合に限り、既存の設定から Brotli だけを除外する例を示しています。

以下の例は、すでにリクエスト展開や自動応答展開を有効にしているアプリケーション向けです。アドバイザリは、使っていないアプリケーションへ AddRequestDecompression の呼び出しや AutomaticDecompression の設定を新たに追加しないよう警告しています。展開を有効にすると、Brotli を除外してもサービス拒否のリスクが生じる可能性があるためです。

ASP.NET Core のリクエスト展開を使っている場合は、既存の設定から br のプロバイダーを削除します。gzip と deflate の既定のプロバイダーは維持されます。

builder.Services.AddRequestDecompression(options =>
{
    options.DecompressionProviders.Remove("br");
});

HttpClient の自動応答展開を使っている場合は、既存のハンドラーのフラグから DecompressionMethods.Brotli を外します。DecompressionMethods.All を指定している場合も、Brotli を含まない指定へ変更します。

var handler = new HttpClientHandler
{
    AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
};

var httpClient = new HttpClient(handler);

BrotliStream などを直接使っている処理は、更新まで信頼できない Brotli データを渡さないようにします。アドバイザリは、これらの変更が通常のリクエストや応答の処理に影響しうるため、適用前のテストを求めています。暫定対策は修正版の適用までのつなぎであり、恒久対策は更新です。

Linux tarball の所有権問題（CVE-2026-114148）の対象と入れ替え手順

CVE-2026-114148 の対象は、Linux の特定の tarball に限られます。通常の Microsoft 公開の .NET Runtime や SDK の tarball まで一律に対象となるわけではありません。

対象となる tarball と source-build の修正版

.NET 8 / 9 で対象となるのは、アーカイブ名が aspnetcore-runtime-、aspnetcore-runtime-composite-、aspnetcore-targeting-pack- で始まる Linux 向けの tarball です。source-build を自前で行わず、Microsoft の配布物を使っているだけの環境も対象になり得ます。source-build の修正版は、SDK の番号で示されています。.NET 10 の source-build では、一般向けの SDK 10.0.114 / 10.0.403 とは異なる -servicing 付きの番号が修正版として示されているため、公式アドバイザリの番号で照合してください。

アドバイザリによると、影響が生じるのは、特権でのアーカイブ展開やコンテナのアーカイブ取り込みなどで、アーカイブ内の数値の所有者情報がそのまま保持された場合です。.NET のバージョン番号だけでは、どのアーカイブから導入したかも、導入先の所有者が適切かも判断できません。ASP.NET Core の runtime や targeting-pack の NuGet パッケージを復元しただけでは、この問題は持ち込まれないとされています。また、source-build のアーカイブはビルド作業の入力であり、それを使ったことが本番の共有 Runtime を導入したことを意味するわけではありません。

上書き展開では解消しない理由と入れ替え手順

問題は既存の導入先に設定されたファイルの所有者にあるため、修正版を同じ場所へ展開し直しても、既存のファイルやディレクトリーの所有者は修正されません。

参考: Microsoft Security Advisory CVE-2026-114148
“extracting over an existing installation does not by itself correct the existing installation”
（既存のインストール先へ上書き展開するだけでは、既存のインストールは修正されない）
https://github.com/dotnet/aspnetcore/security/advisories/GHSA-r6pf-x897-gm86

アドバイザリが示す、利用者が導入した環境の入れ替え手順は次のとおりです。

(
    umask 022
    tar -xzf "$PATCHED_ARCHIVE" -C "$NEW_DOTNET_ROOT" \
        --no-same-owner --no-same-permissions
)

source-build を使うビルドパイプラインでは、入力を修正版の source-build に更新し、展開済みのワークスペースを再利用せず、新しい信頼できるディレクトリーで同じ方法により展開し直します。あわせて、そのアーカイブから作成した下流の Runtime / SDK パッケージやカスタムイメージに所有者情報が引き継がれていないかを確認し、必要に応じて再ビルドします。下流の成果物を実際に導入・配布している場合は、上記の入れ替え手順の対象になります。

配布方式ごとの更新方法と完了条件

.NET アプリケーションでは、Runtime がどこに含まれているかによって、更新すべき対象が変わります。ホストの Runtime を更新して修正が反映されるのは、framework-dependent のアプリケーションだけです。

配布方式別の更新対象と完了条件

NativeAOT について、アドバイザリは、マシンの共有 Runtime を更新しても、NativeAOT の実行ファイルにすでにリンクされたデコーダーは置き換わらないと説明しています。

稼働中の Runtime を確認するときの注意点

マシンに導入済みの Runtime は、次のコマンドで一覧表示できます。

dotnet --list-runtimes

このコマンドで確認できるのは、その dotnet が管理する共有 Runtime の一覧です。self-contained のアプリケーションに同梱された Runtime が更新されたことは、この結果からは判断できません。

参考: .NET Blog「.NET October 2026 Out-of-Band Security Updates」
“Self-contained applications and container deployments must be checked separately”
（self-contained のアプリケーションとコンテナのデプロイは、別途確認する必要がある）
https://devblogs.microsoft.com/dotnet/dotnet-october-2026-oob-security-updates/

運用上は、次の点に注意することをおすすめします（編集上の整理）。

• Runtime を更新しても、再起動していないプロセスは更新前の Runtime を読み込んだまま動作します。
• 1 台のサーバーに複数の導入先がある場合、操作中のシェルの dotnet と、サービスが使う dotnet が異なることがあります。
• コンテナでは、タグを更新しても、稼働中のコンテナが新しいイメージで起動したとは限りません。タグを変えずに再ビルドした場合も含め、稼働中のコンテナや Pod が実際に使っているイメージの digest が、修正済みイメージの digest と一致することを確認します。
• Microsoft の .NET コンテナイメージは今回のリリースに合わせて更新されたと各リリースノートに記載されています。リリースの告知 Issue には、インストーラー、コンテナイメージ、Linux パッケージなど成果物ごとの公開状況の表があり、空欄は公開が確認されていないこと（未公開とは限らない）を示します。利用する配布チャネルの欄を確認したうえで、取得したイメージやパッケージ内の Runtime のバージョンも確認してください。

Windows のスタンドアロンインストーラーは、既定では新しいバージョンの導入が成功した後に以前のバージョンを削除すると、Microsoft サポートの更新情報で説明されています。切り戻しに旧バージョンの Runtime を使う計画がある場合は、削除の動作を事前に確認しておくことをおすすめします。

Blazor WebAssembly の NuGet パッケージは別途更新する

CVE-2026-102870 の修正は、NuGet パッケージの Microsoft.AspNetCore.Components.WebAssembly.Server と Microsoft.AspNetCore.Components.WebAssembly.DevServer に含まれます。.NET 10 では 10.0.14、.NET 11 では 11.0.0-rc.3.26522.148 へ参照を更新します。Microsoft サポートの更新情報によると、今回の再修正は、10 月 13 日の修正における BrowserDebugHost のパッケージングを訂正したものです。そのため、10 月 13 日に 10.0.13 へ更新済みのプロジェクトも、10.0.14 への更新が必要です。

参考: .NET 10.0.14 リリースノート
“updating the shared runtime alone does not update these packages.”
（共有 Runtime を更新するだけでは、これらのパッケージは更新されない）
https://github.com/dotnet/core/blob/main/release-notes/10.0/10.0.14/10.0.14.md

この問題が成立するのは、開発者が影響を受けるパッケージで Blazor WebAssembly アプリケーションをデバッグし、攻撃者が制御するデータを含む式を評価した場合です。影響の中心は開発者の端末であり、本番環境で稼働するアプリケーションを利用者が操作するだけでは成立しません（成立条件はアドバイザリ、影響範囲の整理は編集上の推論）。ただし、プロジェクトの参照が更新されていなければ、次にデバッグする開発者が影響を受けるため、リポジトリー側の更新が必要です。更新後は、デバッガーと開発環境を再起動します。

パッケージの参照は、次の観点で確認します。

• 直接参照: 各プロジェクトファイル（.csproj）の PackageReference
• バージョンの一元管理: 中央パッケージ管理を使っている場合は Directory.Packages.props
• 復元結果: ロックファイル（packages.lock.json）や、復元後に実際に解決されたバージョン
• 間接依存: 他のパッケージ経由で取り込まれていないか

解決されたバージョンは、間接依存を含めて dotnet list package で一覧表示できます。.NET 10 SDK 以降では dotnet package list の形式も使えます。

dotnet list package --include-transitive

特定のパッケージがどの依存関係から取り込まれているかは、.NET 8.0.4xx SDK 以降で使える dotnet nuget why で確認できます。

dotnet nuget why Microsoft.AspNetCore.Components.WebAssembly.Server

--vulnerable オプションや NuGet Audit は、参照先の脆弱性データベースの内容に基づいて判定します。2026 年 10 月 26 日時点で、GitHub Advisory Database の CVE-2026-70197 と CVE-2026-102870 には、10 月 13 日の版（10.0.13 など）を修正版とする情報が残っていました。警告が出ないことだけで完了とせず、10 月 25 日の再修正版を基準に、解決されたバージョンが今回の修正版以上であることを確認してください。

対応完了までの確認手順

ここまでの内容を、運用担当者が実施する作業の順番に整理します。各手順の内容は、公式情報に基づく編集上の提案です。

まとめ

2026 年 10 月の .NET 緊急更新は、新たな 2 件の CVE と、10 月 13 日分の 2 件の再修正で構成されています。対応の要点は、各 CVE の成立条件を見極めたうえで、配布方式に合った方法で修正版を稼働中の環境まで反映させることです。

• 更新先は 8.0.33、9.0.22、10.0.14、プレリリースの 11 RC3 です。
• 10 月 13 日の更新を適用済みでも、今回の修正版が必要です。
• Brotli の影響は、外部データを展開する経路の有無で判断します。
• tarball の所有権問題は、新しい導入先への入れ替えで解消します。
• self-contained、コンテナ、NativeAOT は再発行と再配布が必要です。
• Blazor の NuGet パッケージは、Runtime とは別に更新します。
• 完了の判断は、稼働中のプロセスとイメージの確認で行います。

以上、最後までお読みいただきありがとうございました。