Article

.NETの2026年10月臨時更新:Brotliの修正を実行環境へ届けるには

.NET 8・9・10と.NET 11 RC3に、BrotliとLinux tarballの所有権に関する修正が提供されました。10月13日の更新で不十分だった修正も含まれるため、配布方式に合わせてランタイム更新・再発行・再デプロイを進める必要があります。

Share

こはるの読みどころ

サーバーに新しい.NETを入れたら完了、とは限らないんだね。アプリがどのランタイムを使うかに注目して読んでみよう。

こはるの読みどころ

セキュリティ更新を入れたはずなのに、アプリが使うランタイムには修正が届いていない。.NETの更新では、配布方式によってそんな食い違いが起こります。

2026年10月25日の臨時セキュリティ更新を適用する際も、この違いが判断の分かれ目です。Brotliをどこで処理しているか、そしてランタイムをどこから読み込むかをつなげると、更新すべきものが見えてきます。

Brotliの展開処理は受信APIだけでなくHTTPクライアントにもある

CVE-2026-111497は、Brotli展開時のバッファーオーバーフローです。未認証の攻撃者によるプロセスメモリーの読み取りや破壊につながり得る問題で、対象プラットフォームは限定されていません。.NET Frameworkは対象外です。

確認の入口は、ASP.NET Coreのリクエスト展開、HttpClientの応答の自動展開、System.IO.CompressionのBrotli APIです。リクエスト展開と応答の自動展開は既定で有効ではありませんが、個別の設定やAPI利用まで調べて判断します。

ASP.NET Coreでは、AddRequestDecompressionとUseRequestDecompressionで展開を有効にすると、Content-Encodingに対応するプロバイダーが選ばれます。brはBrotliを表し、実際の展開はリクエスト本文を読む際に行われます。設定箇所から本文の読み取りまで追うと、入力経路を整理できますね。リクエスト展開の公式文書

一方、HttpClientのAutomaticDecompressionは、外部へ送信したリクエストに対する応答を展開する設定です。None以外を指定すると、対応するAccept-Encodingも送信されます。公開APIの設定だけでなく、外部サービスを呼び出す処理も棚卸ししたいところです。AutomaticDecompressionの仕様

Linuxのtarballは取得元によって更新対象が分かれる

Brotliの利用経路とは別に、LinuxではCVE-2026-114148への対応も必要です。対象tarballの安全でない所有権メタデータによって、ローカルの攻撃者がファイルを変更し、権限を昇格できる可能性があります。

.NET 10・11ではsource-build用tarballが対象です。.NET 8・9ではASP.NET Coreのtarball配布も含まれるため、ソースからビルドしていない利用者も関係します。ここは「自前ビルドの有無」だけでは切り分けられません。

source-build利用者は更新済みの成果物を取得してパッケージを再ビルドします。.NET 8・9のASP.NET Core Runtimeをtarballで導入している場合は、更新されたtarballを使ってインストールを更新する、という案内です。運用記録には.NETの系列に加え、どの配布物から導入したかも残しておくと、対象の取り違えを減らせます。

10月13日に更新済みでも、今回の修正版へ進める

Microsoftはできるだけ早い更新を推奨しています。今回の提供版は次のとおりで、.NET 11 RC2利用者にはRC3への更新が案内されています。

使用系列 2026年10月25日の提供版
.NET 8 8.0.33
.NET 9 9.0.22
.NET 10 10.0.14
.NET 11 Release Candidate 3

2026年10月13日の更新では、SocketAsyncEventArgsのメモリー破壊に関するCVE-2026-70197と、Blazor WebAssemblyデバッガーに関するCVE-2026-102870の修正が不十分でした。今回の更新には前者の.NET 8〜11向け、後者の.NET 10・11向けの修正も含まれます。Brotliを使っていないという判断だけで、今回の更新全体を不要とは扱えません。

ランタイムを共有するアプリと同梱するアプリで反映方法を変える

フレームワーク依存型は、実行環境にあるランタイムを利用します。自己完結型はアプリにランタイムを同梱するため、ホスト側に新しい.NETを入れても同梱物は変わりません。この配布モデルの違いが、更新手順を分ける理由です。.NETの配布方式

フレームワーク依存型では、アプリの対象系列のランタイムを更新して再起動します。自己完結型では修正版ランタイムを含めて再ビルド・再発行し、その成果物を配布します。コンテナは更新済み.NETイメージを使って再ビルド・再デプロイする必要があります。

ビルド設定も更新の一部です。自己完結型のRuntimeFrameworkVersionは同梱するランタイムの版を指定し、フレームワーク依存型のrollForwardをDisableにすると指定版だけに束縛されます。こうした固定設定があるなら、更新したランタイムが選ばれるかを併せて見ます。ランタイムのバージョン選択規則

インストール済みランタイムの一覧は、次のコマンドで取得できます。

sh
dotnet --list-runtimes

これは実行したdotnetのアーキテクチャに対応する一覧です。dotnet --versionが示すのはSDKの版なので、役割が異なります。また、この一覧だけで自己完結型の同梱物や別コンテナまで更新済みとは判定できません。dotnetコマンドの仕様

更新の完了点は、修正版をダウンロードした時点ではなく、各アプリがその修正を使って動き始めた時点です。Brotliの入力経路とtarballの取得元を調べ、配布方式に合う更新を実施し、起動と主要機能の動作まで確かめる。この一続きの作業として扱うと、ランタイムの更新漏れを減らせます。

出典

Share

Related Articles

カテゴリやタグが近い記事を続けて読めるように並べています。