.NET 2026年6月更新の変更点|10.0.9・9.0.17・8.0.28と3件の脆弱性

「.NET and .NET Framework June 2026 servicing releases updates」で最初に確認すべき点は、.NET 8・9・10に3件の脆弱性修正が入り、最新パッチへの更新が必要になったことです。更新後のバージョンは.NET 10.0.9、9.0.17、8.0.28です。一方、.NET Frameworkには2026年6月の新しいセキュリティ更新・品質更新はありません。(Microsoft for Developers)

特に、SignalRやBlazor Serverを公開しているWebサービス、TARファイルを扱うシステム、共有のビルドサーバーは優先的な確認が必要です。単に開発PCのSDKを更新するだけでなく、実行サーバー、コンテナイメージ、自己完結型アプリまで更新対象に含めてください。

目次

.NET DevBlogsの2026年6月アップデートで変わったこと

Microsoftが2026年6月9日に公開した今回の更新は、新しいメジャーバージョンへの移行ではなく、既存バージョン向けのサービス更新です。

対象更新後のランタイム対応する主なSDK更新内容
.NET 1010.0.910.0.301、10.0.109セキュリティ修正、非セキュリティ修正
.NET 99.0.179.0.315、9.0.118セキュリティ修正、非セキュリティ修正
.NET 88.0.288.0.422、8.0.128セキュリティ修正、非セキュリティ修正
.NET Framework変更なし変更なし2026年6月の新規更新なし

SDKをインストールすると対応するランタイムも含まれます。ただし、本番サーバーにランタイムだけを導入している場合は、SDKではなく.NET Runtime、ASP.NET Core Runtime、Windows Desktop Runtime、Hosting Bundleなど、用途に合った更新が必要です。(GitHub)

修正された3件の脆弱性

今回の更新では、.NET 8、.NET 9、.NET 10に共通して次の脆弱性が修正されました。

CVE内容影響を受けやすい環境優先度の判断
CVE-2026-45591ASP.NET Coreのサービス拒否脆弱性。深くネストされたMessagePack配列により、SignalRやBlazor Serverで制御されない再帰が発生する可能性SignalR、Blazor Server、MessagePackを使用する外部公開サービス最優先。認証前にネットワーク経由で攻撃される可能性があり、CVSSは7.5
CVE-2026-45491System.Formats.Tarのパストラバーサル。シンボリックリンクを悪用して任意のファイルを書き込まれる可能性アップロードされたTARファイルや外部取得したアーカイブを展開するシステム信頼できないアーカイブを扱う場合は優先度が高い。CVSSは6.8
CVE-2026-45490.NET SDKの名前付きパイプ処理に関する権限昇格脆弱性。ローカルの攻撃者が任意のファイルを作成・切り詰めできる可能性開発PC、共有CI/CDサーバー、複数ユーザーが利用するビルドエージェントSDKを導入している共有環境では優先度が高い。CVSSは6.0

一般公開しているSignalRやBlazor Serverでは、CVE-2026-45591の影響を受ける条件に該当しやすいため、通常の月次メンテナンスを待たずに更新を検討すべきです。(GitHub)

.NET 10.0.9の主な非セキュリティ変更

.NET 10.0.9には、脆弱性修正以外にも安定性や開発体験に関する変更が含まれています。主なものは次のとおりです。

  • コールドスタート時にData ProtectionのKeyRingProviderがスレッドプールを圧迫する問題を修正
  • Blazorのresource-collection.js.gzに正しいgzipフッターを書き込むよう修正
  • バリデーションのソースジェネレーターでインデクサープロパティを除外
  • .NET 10 SDKにmcpserverプロジェクトテンプレートを追加
  • オブジェクトが大量に固定される状況でのGCヒープサイズ処理を修正
  • MsQuicを更新

Webアプリの起動直後に応答が遅くなる環境や、Blazorの静的ファイルをCDN・プロキシ経由で配信している環境では、セキュリティ以外の改善も確認対象になります。(GitHub)

誰に影響するアップデートか

利用状況影響と対応
ASP.NET Coreを外部公開している対象ランタイムを更新し、SignalR、Blazor Server、MessagePackの使用有無を確認する
TARファイルを展開しているSystem.Formats.Tarの利用箇所を調査し、外部ファイルを使った回帰テストを行う
CI/CDやビルドサーバーにSDKを導入しているSDKを最新パッチへ更新する。共有エージェントは優先度を上げる
IISでASP.NET Coreをホストしているサーバー側のHosting Bundleを更新し、アプリプール再起動後に動作確認する
Linuxサーバーで動かしている導入時と同じパッケージマネージャーまたは管理方法でランタイムを更新する
DockerやKubernetesを利用している更新済みベースイメージでビルドし直し、新しいコンテナを再デプロイする
自己完結型で配布しているOS側の.NETを更新するだけでは不十分。アプリを再発行して配布し直す
.NET Frameworkだけを利用している今回の.NET Framework向け新規パッチはない。通常のWindows Updateは継続する
市販の.NETデスクトップアプリを利用しているアプリにランタイムが内包されている場合があるため、開発元の更新情報も確認する

特に見落とされやすいのが、コンテナと自己完結型アプリです。ホストOSの.NETを更新しても、コンテナ内部やアプリに同梱されたランタイムは更新されません。自己完結型アプリは、新しいランタイムを使用して再発行する必要があります。(Microsoft Learn)

現在のバージョンを確認する手順

まず、開発PCと本番サーバーの両方で、インストール済みのSDKとランタイムを確認します。

dotnet --info
dotnet --list-sdks
dotnet --list-runtimes

更新後は、利用中のメジャーバージョンに応じて次のランタイムが表示されることを確認します。

Microsoft.NETCore.App 10.0.9
Microsoft.AspNetCore.App 10.0.9

または、次のいずれかです。

Microsoft.NETCore.App 9.0.17
Microsoft.AspNetCore.App 9.0.17

Microsoft.NETCore.App 8.0.28
Microsoft.AspNetCore.App 8.0.28

dotnet --versionで確認できるのは、現在選択されているSDKです。Webサーバーに導入されたASP.NET Core Runtimeまで確認するには、dotnet --list-runtimesを使用してください。

SDKが更新後の版に切り替わらない場合

最新SDKをインストールしても、プロジェクトのglobal.jsonで古いSDKが固定されていると、ビルド時に旧バージョンが選択されることがあります。

次の項目を確認してください。

  • リポジトリ直下や親フォルダーにglobal.jsonがないか
  • CI/CDのビルドイメージが古いままではないか
  • DOTNET_ROOTが別の.NETインストール先を指していないか
  • x64版とArm64版など、異なるアーキテクチャーのSDKを参照していないか
  • 実行ユーザーと管理者でPATHの内容が異なっていないか

環境別の更新方法

Windowsの開発PC

Visual Studioで.NETを管理している場合は、Visual Studio Installerから更新します。スタンドアロン版を使用している場合は、対象バージョンの最新SDKを導入します。

SDKには.NET Runtime、ASP.NET Core Runtime、Windows Desktop Runtimeが含まれます。ただし、Visual Studioが管理する.NETと、システム全体にインストールされた.NETが別になっているケースがあるため、更新後はコマンドで確認してください。(Microsoft Learn)

IISを利用するWindows Server

IIS上でASP.NET Coreアプリを運用している場合は、対象バージョンのHosting Bundleを更新します。

更新作業では、次の順番で確認すると安全です。

  1. 対象サーバーのランタイムとHosting Bundleを棚卸しする
  2. ステージング環境で更新する
  3. アプリの起動、ログイン、暗号化キー、SignalR接続を確認する
  4. メンテナンス時間内に本番へ適用する
  5. アプリプールまたはIISを再起動する
  6. dotnet --list-runtimesとアプリログで反映を確認する

Data Protectionを利用しているサービスでは、認証Cookieや共有キーリングの読み込みもテスト対象に含めてください。

Linuxサーバー

APT、DNF、YUMなどのパッケージマネージャーで導入した場合は、原則として同じ経路から更新します。手動展開やdotnet-installスクリプトを使っている環境では、自動更新されないため個別対応が必要です。

複数の.NETが共存している場合は、サービス起動スクリプトのDOTNET_ROOTや実行パスも確認してください。(Microsoft Learn)

Docker・Kubernetes

ベースイメージが更新されても、既存のアプリイメージや起動済みコンテナには自動反映されません。

FROM mcr.microsoft.com/dotnet/aspnet:10.0

このように移動タグを使用している場合でも、更新されたベースイメージを取得して再ビルドする必要があります。

docker pull mcr.microsoft.com/dotnet/aspnet:10.0
docker build --pull --no-cache -t example-app:patched .

本番では、イメージスキャンやスモークテストを行ったうえで、ローリング更新などにより再デプロイします。今回のリリースに合わせて公式.NETコンテナイメージも更新されています。(Microsoft for Developers)

設定変更・移行・料金・期限はどうなるか

確認項目結論
設定変更公式告知では、新しい設定項目への切り替えや必須の構成変更は案内されていない
メジャー移行2026年6月パッチを適用するだけなら、.NET 8から10などへのメジャー移行は不要
料金今回の更新に伴う料金改定や有料プランの追加は案内されていない
パッチ適用期限固定の締め切りは示されていないが、セキュリティ修正のため早期適用が推奨される
将来の移行期限.NET 8と.NET 9は2026年11月10日にサポート終了予定

.NETのサービス更新は原則として毎月提供され、各パッチは次のサービス更新が公開されるまでがサポート対象です。Microsoftのサポートを受ける場合も、対象メジャーバージョンの最新サービスレベルへの更新が求められます。(Microsoft Learn)

サポート期限は次のとおりです。

バージョン種別サポート終了予定
.NET 10LTS2028年11月14日
.NET 9STS2026年11月10日
.NET 8LTS2026年11月10日

.NET 8と.NET 9は、今回のパッチを適用すれば当面の脆弱性には対応できます。ただし、2026年11月10日以降は新しいセキュリティ更新を受け取れなくなるため、並行して.NET 10への移行計画を進める必要があります。新規開発や長期運用を前提とするシステムでは、.NET 10 LTSを移行先の第一候補にすると判断しやすいでしょう。(Microsoft Learn)

更新時に失敗しやすいポイント

開発PCだけ更新して本番サーバーを更新していない

SDK更新はビルド環境への対策です。本番サーバーがフレームワーク依存型の場合は、本番側のランタイムも更新しなければ脆弱性が残ります。

コンテナのタグだけ確認して再ビルドしていない

Dockerfileが同じタグでも、すでに作成済みのアプリイメージは古いレイヤーを保持しています。必ず新しいベースイメージを取得し、アプリイメージを再作成してください。

自己完結型アプリをホスト側の更新だけで済ませる

自己完結型アプリには.NETランタイムが含まれます。そのため、ホストOSのランタイム更新では修正されません。更新済みSDKで再発行し、成果物を置き換える必要があります。

.NETと.NET Frameworkを混同する

今回更新されたのは、主にモダン.NETの8、9、10です。.NET Frameworkについては、2026年6月の新しいセキュリティ更新・非セキュリティ更新はありません。.NET Frameworkだけを利用している端末へ、.NET 8や10を追加インストールしても代替にはなりません。

正常性確認をトップページだけで終える

今回の影響箇所に合わせ、少なくとも次の機能を確認してください。

  • SignalRの接続、再接続、メッセージ送受信
  • Blazor Serverの画面遷移と長時間接続
  • TARファイルの展開と保存先制御
  • 認証CookieとData Protection
  • CI/CDの復元、ビルド、テスト、発行
  • コンテナ起動後のヘルスチェック
  • ログ、CPU使用率、メモリ使用量、例外件数

まず実施すべき対応

最初に開発環境、本番サーバー、コンテナ、CI/CDの.NETバージョンを棚卸ししてください。その後、利用中の系列を.NET 10.0.9、9.0.17、8.0.28のいずれかへ更新します。

コンテナと自己完結型アプリは再ビルド・再デプロイが必要です。SignalR、Blazor Server、TAR展開、共有ビルドサーバーを利用している場合は、通常より優先度を上げて対応してください。

.NET 8または.NET 9を運用している組織は、今回のパッチ適用を短期対応、2026年11月10日までの.NET 10移行を中期対応として分けて管理すると、更新漏れを防ぎやすくなります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次