2026年7月14日に公開された.NET servicing updateでは、.NET 10を10.0.10、.NET 9を9.0.18、.NET 8を8.0.29へ更新します。.NET Frameworkは、Windowsのバージョンとインストール済みの.NET Frameworkに対応する2026年7月の累積更新プログラムを適用してください。Microsoftは、.NET 10・9・8に影響する17件のCVEを、このservicing updateで修正済みとしています。(Microsoft for Developers)
実務上のポイントは、開発端末のSDKだけを更新して終わらせないことです。本番サーバーの共有runtime、ASP.NET Core Runtime、Windows Desktop Runtime、IIS Hosting Bundle、コンテナイメージ、self-containedアプリをそれぞれ確認し、必要な環境では再build・再deployまで実施する必要があります。
2026年7月.NET servicing updateの更新先
2026年7月の修正を含むruntime patchと、それを収録したSDKは次のとおりです。SDKのバージョン番号とruntimeのバージョン番号は一致しないため、別々に確認してください。(GitHub)
| 使用中のbranch | 更新後のruntime | runtimeを含むSDK | 主な更新対象 |
|---|---|---|---|
| .NET 10 | 10.0.10 | 10.0.302、10.0.110 | SDK、.NET Runtime、ASP.NET Core Runtime、Desktop Runtime、Hosting Bundle、コンテナ |
| .NET 9 | 9.0.18 | 9.0.316、9.0.119 | SDK、.NET Runtime、ASP.NET Core Runtime、Desktop Runtime、Hosting Bundle、コンテナ |
| .NET 8 | 8.0.29 | 8.0.423、8.0.129 | SDK、.NET Runtime、ASP.NET Core Runtime、Desktop Runtime、Hosting Bundle、コンテナ |
| .NET Framework | OSごとに異なる | SDKではなくWindows更新として配布 | Windows Update、WSUS、Microsoft Update Catalog |
複数のSDKが記載されているのは、同じ.NET branchに異なるSDK feature bandが存在するためです。たとえば、現在10.0.1xx系を使用している環境では10.0.110、10.0.3xx系では10.0.302を選ぶと、feature bandを不用意に変更せずにセキュリティ修正を取り込めます。
global.jsonでSDKを固定しているプロジェクトは、SDKをマシンへインストールしただけでは新しいバージョンが選択されないことがあります。CI/CDの設定、開発コンテナ、GitHub ActionsやAzure PipelinesなどのSDK指定も併せて更新してください。(Microsoft Learn)
.NET 10・9・8で修正された17件のCVE
Microsoftの統合servicing update記事では、次の17件が.NET 10.0、.NET 9.0、.NET 8.0に適用される修正として掲載されています。(Microsoft for Developers)
| CVE番号帯 | 修正対象として掲載されたCVE |
|---|---|
| CVE-2026-473xx | CVE-2026-47300、CVE-2026-47302、CVE-2026-47303、CVE-2026-47304 |
| CVE-2026-505xx | CVE-2026-50524、CVE-2026-50525、CVE-2026-50526、CVE-2026-50527、CVE-2026-50528 |
| CVE-2026-506xx | CVE-2026-50646、CVE-2026-50648、CVE-2026-50649、CVE-2026-50650、CVE-2026-50651、CVE-2026-50659 |
| その他 | CVE-2026-56170、CVE-2026-57108 |
これらには、リモートコード実行、権限昇格、サービス拒否、改ざん、セキュリティ機能のバイパス、なりすましに分類される問題が含まれます。ただし、同じCVEでも.NETと.NET Frameworkで影響の説明が異なる場合があるため、リスク評価では対象製品ごとのMSRC情報を確認する必要があります。(GitHub)
CVE-2026-56170とCVE-2026-56158の表記差に注意
Microsoftの公式文書間には、CVE番号の表記が一致していない箇所があります。
統合servicing update記事ではCVE-2026-56170が掲載されています。一方、.NET 10.0.10、9.0.18、8.0.29の個別release notesでは、その位置にCVE-2026-56158が掲載されています。.NET Frameworkの2026年7月release notesにもCVE-2026-56158が記載されています。(Microsoft for Developers)
このため、更新完了の判定を手作業で転記したCVE一覧だけに依存するのは避けてください。変更管理票には参照した公式文書を記録し、技術的な適用判定は次のpatch versionを基準にするのが安全です。
- .NET 10：10.0.10以上
- .NET 9：9.0.18以上
- .NET 8：8.0.29以上
- .NET Framework：対象OSと導入済みバージョンに対応する2026年7月のKB
.NET Frameworkは17件のCVEとは別に確認する
「17件」という数字は、Microsoftの統合記事で.NET 10・9・8に対して示されたものです。.NET Frameworkの2026年7月累積更新には、重複するCVEに加えて.NET Framework固有のCVEも含まれており、公式release notesには18件のセキュリティ改善が記載されています。したがって、.NET 10・9・8のruntimeを更新しても、.NET Frameworkの更新を適用したことにはなりません。(Microsoft Learn)
同じWindows Serverで、ASP.NET Coreアプリと従来のASP.NET、Windowsサービス、WPFアプリが混在している場合は、次の2系統を個別に管理します。
- .NET 10・9・8のruntime、Hosting Bundle、アプリケーション成果物
- Windows Updateで提供される.NET Framework累積更新
更新方法はデプロイ方式によって異なる
.NETのセキュリティ更新で最も失敗しやすいのは、すべてのアプリを同じ方法で更新しようとすることです。特にframework-dependentとself-containedでは、必要な作業が大きく異なります。
| デプロイ方式 | 修正を反映するための作業 | 再build・再deploy |
|---|---|---|
| framework-dependent | 実行ホストの共有runtimeを更新し、アプリのプロセスを再起動 | runtime修正だけなら既存バイナリの再buildは必須ではないが、検証と成果物統一のため推奨 |
| self-contained | patched SDKとruntime packで再publishする | 必須 |
| コンテナ | build用と実行用の両方のbase imageを更新し、イメージを再buildする | 必須 |
| IIS上のASP.NET Core | Windows Hosting Bundleを更新し、アプリプールまたはIISを再起動する | self-containedまたはコンテナなら必須 |
| .NET Framework | OSに対応する累積更新をWindows UpdateやWSUSで適用する | 通常はアプリの再build不要。再起動が必要になる場合あり |
framework-dependentアプリは、実行環境にインストールされている同一major・minor内の最新patchへ、原則として自動的にroll-forwardします。一方、self-containedアプリはruntimeを成果物の中に含むため、サーバーへ新しい共有runtimeをインストールしても、既存成果物内のruntimeは更新されません。(Microsoft Learn)
更新前にSDK・runtime・アプリの状態を棚卸しする
最初に、開発端末、build agent、本番サーバーで次のコマンドを実行します。
dotnet --info
dotnet --list-sdks
dotnet --list-runtimesdotnet --versionだけで判定するのは不十分です。このコマンドが示すのは、現在のディレクトリやglobal.jsonの条件に基づいて選択されたSDKです。インストール済みのすべてのSDKや、本番で使用されるruntimeを確認するには、--list-sdksと--list-runtimesを使用します。(Microsoft Learn)
runtime一覧で確認する項目
ASP.NET Coreを実行するサーバーでは、少なくとも次の2系統を確認します。
Microsoft.NETCore.App 10.0.10
Microsoft.AspNetCore.App 10.0.10WindowsのWPFまたはWindows Formsアプリでは、必要に応じて次のruntimeも確認します。
Microsoft.WindowsDesktop.App 10.0.10.NET 9または.NET 8を使用している場合は、それぞれ9.0.18、8.0.29になっていることを確認してください。
ただし、使用していないDesktop Runtimeなどを、確認のためだけに追加インストールする必要はありません。アプリの種類に応じて必要なruntimeだけを管理します。
プロジェクトとCI/CDで確認する項目
リポジトリでは、次のファイルや設定を検索します。
global.json
*.csproj
*.fsproj
Dockerfile
docker-compose.yml
Directory.Build.props
GitHub Actionsのworkflow
Azure PipelinesのYAML特に確認したいのは次の項目です。
global.jsonで古いSDKが固定されていないかTargetFrameworkがnet10.0、net9.0、net8.0のどれかSelfContainedがtrueになっていないかRuntimeIdentifierやRuntimeIdentifiersが指定されているか- Dockerfileの
FROMが古いpatchやdigestを参照していないか - build agentに更新後のSDKが導入されているか
.NET 10・9・8を安全に更新する手順
使用中のSDK feature bandに合わせて更新する
まず、現在使用しているSDKのfeature bandを確認します。
| 現在の系統 | 2026年7月の更新先 |
|---|---|
| 10.0.1xx | 10.0.110 |
| 10.0.3xx | 10.0.302 |
| 9.0.1xx | 9.0.119 |
| 9.0.3xx | 9.0.316 |
| 8.0.1xx | 8.0.129 |
| 8.0.4xx | 8.0.423 |
SDKを更新したら、global.jsonで完全なバージョンを固定している場合は、その値も変更します。
{
"sdk": {
"version": "10.0.302",
"rollForward": "latestPatch"
}
}SDKのfeature bandを変更すると、コンパイラ、MSBuild、workload、analyzerなどの変更範囲が広がる場合があります。今回の目的がセキュリティ修正の適用であれば、まず同じfeature band内の更新を選ぶと変更範囲を抑えられます。
本番ホストに必要なruntimeを適用する
アプリの種類に応じて、更新するコンポーネントを選択します。
| アプリの種類 | 主に更新するコンポーネント |
|---|---|
| コンソール、バックグラウンドサービス | .NET Runtime |
| Kestrelで動くASP.NET Core | ASP.NET Core Runtime |
| IISで動くASP.NET Core | Windows Hosting Bundle |
| WPF、Windows Forms | .NET Desktop Runtime |
| buildサーバー、開発端末 | .NET SDK |
SDKには対応する.NET Runtimeが含まれるため、SDKをインストールしたbuild端末では、通常は同じruntimeを別途インストールする必要はありません。一方、本番サーバーにSDKを入れていない場合は、アプリに適したruntimeまたはHosting Bundleを個別に更新します。(GitHub)
コンテナのbuild stageとruntime stageを両方更新する
マルチステージbuildでは、最終stageだけでなくSDKを使用するbuild stageも確認します。.NET 10のASP.NET Coreアプリなら、たとえば次のように更新します。
FROM mcr.microsoft.com/dotnet/sdk:10.0.302 AS build
# restore、build、publish処理
FROM mcr.microsoft.com/dotnet/aspnet:10.0.10 AS final
# publish成果物をコピーコンソールアプリではaspnetではなくruntime、self-containedアプリでは構成に応じてruntime-depsを使用します。
既存環境がAlpine、Ubuntu、Windows Server CoreなどのOS variantを指定している場合は、セキュリティ更新と同時に意図せずOS familyを変更しないようにしてください。たとえば-alpineや-nobleなどのsuffixを維持したまま、patchまたはdigestを更新します。
base imageの最新版を取得してbuildする例は次のとおりです。
docker build --pull --no-cache -t sample-app:2026-07 .レジストリ上のタグが更新されても、すでに稼働しているコンテナやPodの内容は自動的には置き換わりません。新しいイメージをbuildしてレジストリへpushし、Deployment、Container Apps、App Service、ECSなどの実行環境で再deployしてください。.NET公式のコンテナイメージも今回のreleaseに合わせて更新されています。(Microsoft for Developers)
restore・test・publishをpatched SDKで実行する
SDKを切り替えた後は、キャッシュされた古い成果物だけを再利用せず、CI/CDでrestoreから実行します。
dotnet restore
dotnet test -c Release
dotnet publish -c Release -o ./artifacts/publish最低限、次のテストを実施します。
- アプリケーションの起動とhealth check
- 認証、認可、Cookie、トークン処理
- HTTPS、外部API、プロキシ経由の通信
- JSONやXMLのシリアライズ、デシリアライズ
- ファイルアップロード、圧縮、画像処理
- データベース接続とトランザクション
- バックグラウンドジョブ、キュー、定期処理
- IIS、Windowsサービス、systemdサービスの再起動
今回の更新にはセキュリティ修正だけでなく、非セキュリティ修正も含まれています。そのため、「patch更新だから動作確認は不要」と判断せず、主要な処理を対象に回帰テストを行ってください。(Microsoft for Developers)
.NET Frameworkの該当KBを選ぶ
.NET Frameworkには、.NET 10・9・8のような単一の「2026年7月patch version」はありません。Windowsのバージョンと、端末に入っている.NET Framework 3.5、4.7.2、4.8、4.8.1などの組み合わせによって適用されるKBが変わります。
代表的な更新は次のとおりです。(Microsoft Learn)
| OS | 主な2026年7月.NET Framework更新 |
|---|---|
| Windows 11 26H1 | .NET Framework 4.8.1：KB5101002、.NET Framework 3.5製品更新：KB5101014 |
| Windows 11 25H2 | .NET Framework 3.5／4.8.1：KB5100998 |
| Windows 11 24H2 | .NET Framework 3.5／4.8.1：KB5101001 |
| Windows 11 22H2／23H2 | .NET Framework 3.5／4.8.1：KB5101004 |
| Microsoft server operating system 24H2 | .NET Framework 3.5／4.8.1：KB5100998 |
| Windows Server 2022 | 更新提示用KB5102206。導入済みFrameworkに応じてKB5101010またはKB5101005 |
| Windows 10 21H2／22H2 | 更新提示用KB5102202またはKB5102203。導入済みFrameworkに応じてKB5101006またはKB5101000 |
| Windows 10 1809／Windows Server 2019 | 更新提示用KB5102201。導入済みFrameworkに応じてKB5100989またはKB5101008 |
| Windows 10 1607／Windows Server 2016 | KB5099535またはKB5101007 |
| Windows Server 2012／2012 R2 | OSとFrameworkのバージョンに対応するSecurity and Quality Rollup |
Microsoftは、表中の「OS行のKB」が更新を提示するために使われ、端末のインストール済み更新には表示されない場合があると説明しています。監査や適用確認では、実際にインストールされた.NET Framework固有のKBを確認してください。(Microsoft Learn)
.NET Framework更新は、Windows Update、Windows Update for Business、Microsoft Update Catalog、WSUSから配布されます。影響するファイルが使用中だった場合は再起動が必要になるため、更新前に.NET Frameworkアプリを終了し、サーバーでは再起動を含むメンテナンス枠を確保します。Microsoftは2026年7月の.NET Framework更新について、現時点で既知の問題を認識していないとしています。(マイクロソフトサポート)
更新後に確認すべきこと
ホストにpatched runtimeが存在するか確認する
dotnet --list-runtimes
dotnet --list-sdks使用中のbranchについて、次のいずれかが表示されることを確認します。
Microsoft.NETCore.App 10.0.10
Microsoft.AspNetCore.App 10.0.10
Microsoft.NETCore.App 9.0.18
Microsoft.AspNetCore.App 9.0.18
Microsoft.NETCore.App 8.0.29
Microsoft.AspNetCore.App 8.0.29Windowsデスクトップアプリでは、該当するMicrosoft.WindowsDesktop.Appも確認します。
実行中のコンテナを確認する
新しいイメージから起動したコンテナ内で確認します。
docker run --rm <更新後のイメージ名> dotnet --infoKubernetesでは、再deploy後のPodが新しいimage digestを使用していることを確認します。タグ名が同じでもdigestが古いままなら、実行環境は更新されていません。
self-containedアプリはホストのruntime一覧だけで判定しない
self-containedアプリでは、dotnet --list-runtimesに新しい共有runtimeが表示されても、配布済みアプリ内のruntimeが更新された証拠にはなりません。
次の情報を適用証跡として残します。
- patched SDKを使用したCI/CDのbuildログ
- publishを実行した日時
- 成果物のハッシュ値
- コンテナのimage digest
- SBOMに記録されたruntime pack
- ステージング環境と本番環境のデプロイID
.NET FrameworkのKBを確認する
Windows Updateの更新履歴、WSUS、Microsoft Configuration Manager、Intuneなどのレポートで、対象OSに対応した.NET Framework固有のKBが成功状態になっているか確認します。
更新後は、IISアプリ、Windowsサービス、タスクスケジューラ、WPFやWindows Formsの業務アプリを起動し、イベントログにCLRや.NET Runtime関連のエラーが発生していないか確認してください。
よくある適用ミス
- 開発端末のSDKだけを更新し、本番サーバーのruntimeを更新していない
dotnet --versionだけを見て、ASP.NET Core RuntimeやDesktop Runtimeを確認していないglobal.jsonが古いSDKを固定したままになっている- self-containedアプリなのに、サーバーの共有runtimeだけを更新している
- Dockerfileのruntime stageだけを更新し、SDK stageを古いままにしている
- base imageのタグを書き換えたが、イメージを再build・再deployしていない
- IISサーバーで.NET Runtimeだけを更新し、Hosting Bundleを確認していない
- .NET 10・9・8の更新だけで、同じサーバー上の.NET Frameworkも修正されたと判断している
- 更新後にアプリプール、Windowsサービス、コンテナを再起動していない
- CVE番号の転記だけで完了判定し、実際のruntime patchやKBを確認していない
.NET 8と.NET 9は.NET 10への移行計画も必要
2026年7月時点で、.NET 10はLTSのActive Support、.NET 9と.NET 8はMaintenance Supportに入っています。公式サポート期限は、.NET 9と.NET 8が2026年11月10日、.NET 10が2028年11月14日です。(Microsoft)
したがって、.NET 8または.NET 9を使用している組織は、今回のpatchを見送って直接.NET 10へ移行するのではなく、次の順序で対応します。
- まず9.0.18または8.0.29へ更新して現在の脆弱性を解消する
- 並行して.NET 10への互換性確認を開始する
- 2026年11月10日より前に本番移行を完了する
- .NET 8・9のruntime、SDK、コンテナイメージを環境から段階的に廃止する
セキュリティ更新とmajor version移行を一つの変更作業にまとめると、障害時の原因切り分けが難しくなります。緊急性の高いpatch適用と、.NET 10への移行は別の変更単位で管理するのが現実的です。
適用完了の判断基準
2026年7月.NET servicing updateは、インストーラーを実行しただけでは完了ではありません。次の項目をすべて満たした時点で、更新完了と判断します。
- [ ] 使用中の全branchを10.0.10、9.0.18、8.0.29へ更新した
- [ ] build agentのSDKと
global.jsonを更新した - [ ] .NET Runtime、ASP.NET Core Runtime、Desktop Runtime、Hosting Bundleを用途別に確認した
- [ ] self-containedアプリを再publish・再deployした
- [ ] コンテナのbuild stageとruntime stageを更新した
- [ ] 新しいimage digestでコンテナやPodを再作成した
- [ ] 該当する.NET Frameworkの累積更新を適用した
- [ ] 更新後のruntime一覧、KB、buildログ、image digestを証跡として保存した
- [ ] 回帰テストと本番監視で異常がないことを確認した
- [ ] .NET 8・9を使用中の場合は.NET 10への移行期限を設定した
最初に行うべき作業は、dotnet --list-sdksとdotnet --list-runtimesによる棚卸しです。その結果を、プロジェクトのglobal.json、Dockerfile、self-contained設定、Windowsの.NET Framework更新履歴と突き合わせ、環境ごとの更新対象を確定してください。
コメント