2026年4月21日にMicrosoftが公開した .NET 10.0.7 out-of-band security update は、通常の月例更新を待たずに提供された緊急性の高いセキュリティ更新です。結論から言うと、Microsoft.AspNetCore.DataProtection を使う .NET 10 系アプリ、とくに 10.0.0〜10.0.6 を参照している環境は、10.0.7 への更新と影響調査を優先してください。Microsoftは、この更新が Microsoft.AspNetCore.DataProtection に導入されたセキュリティ問題に対処するOOB更新だと説明しています。(Microsoft for Developers)
今回のポイントは「パッケージを上げれば終わり」と考えないことです。影響を受けたアプリがインターネットに公開されていた場合、Data Protectionキーリングのローテーション、認証Cookie・リフレッシュトークン・APIキー・パスワードリセットリンクなどの監査まで含めて対応を設計する必要があります。Microsoftのアドバイザリでも、影響環境では Microsoft.AspNetCore.DataProtection を 10.0.7 以降へ更新し、必要に応じてData Protectionキーリングをローテーションすることが示されています。(GitHub)
.NET 10.0.7 out-of-band security updateでまず押さえるべき更新ポイント
.NET 10.0.7は、2026年4月21日に公開された .NET 10 系の更新です。Microsoftのリリースノートでは、.NET 10.0.7にセキュリティ修正が含まれ、CVE-2026-40372 に対応していることが明記されています。(GitHub)
| 確認項目 | 内容 |
|---|---|
| 公開日 | 2026年4月21日 |
| 更新種別 | Out-of-band、OOBのセキュリティ更新 |
| 主な対象 | ASP.NET Core Data Protectionを利用する .NET 10 系アプリ |
| 修正対象 | CVE-2026-40372 |
| 影響するパッケージ | Microsoft.AspNetCore.DataProtection |
| 影響バージョン | 主に 10.0.0〜10.0.6 |
| 推奨対応 | 10.0.7 以降へ更新、再ビルド、再デプロイ、影響環境ではキーリングローテーションとトークン監査 |
Microsoftのブログでは、.NET 10.0.6のPatch Tuesdayリリース後、一部顧客から復号処理の失敗が報告され、その調査の中で脆弱性も確認されたと説明されています。問題は、管理対象の認証付き暗号化処理がHMAC検証タグを誤ったペイロードのバイト列に対して計算し、その計算結果を破棄する可能性がある点にあります。これにより、権限昇格につながる可能性があるとされています。(Microsoft for Developers)
なぜData Protectionの脆弱性は重要なのか
ASP.NET Core Data Protectionは、Webアプリで信頼済みの状態を安全に保持し、後で復元するための暗号化基盤です。Microsoft Learnでは、Data Protectionが認証CookieやBearer tokenのように、真正性・完全性・改ざん防止が必要なデータを扱う代表例として説明されています。(Microsoft Learn)
実務上、Data Protectionは次のような領域に関わります。
- 認証Cookie
- CSRF対策のAntiforgery token
- TempData
- OpenID Connectのstateパラメーター
- アプリ独自の
IDataProtector.Protect出力 - Redis、Azure Storage、Entity Framework Coreなどを使ったData Protectionキー管理
今回の脆弱性では、破損した検証処理により、Data Protectionの真正性チェックを通過するペイロードの偽造や、保護済みペイロードの復号につながる可能性があるとリリースノートで説明されています。対象になり得るものとして、認証Cookie、Antiforgery token、TempData、OIDC stateなどが挙げられています。(GitHub)
これは、単なるアプリケーションエラーではありません。Identityチームにとっては「不正な認証状態が作られた可能性」、Security Adminにとっては「攻撃期間と影響範囲の特定」、Complianceチームにとっては「修正適用の証跡と追加措置の説明」が必要になる更新です。
影響を受ける可能性が高い環境
Microsoftのアドバイザリでは、影響を受ける条件がかなり具体的に整理されています。とくに優先して確認すべきなのは、Microsoft.AspNetCore.DataProtection の 10.0.6 を参照し、非Windows環境で実行されている .NET 10 アプリです。(GitHub)
| 判定 | 確認すべき環境 | 実務での見方 |
|---|---|---|
| 優先確認 | Microsoft.AspNetCore.DataProtection 10.0.6を直接または推移的に参照している .NET 10 アプリ | Linux、macOS、コンテナ、Kubernetes上のASP.NET Coreアプリを優先して棚卸しする |
| 優先確認 | Microsoft.AspNetCore.DataProtection.StackExchangeRedis、.EntityFrameworkCore、.AzureKeyVault、.AzureStorage、.Redis など経由でData Protectionを利用しているアプリ | 直接参照がなくても、推移的依存関係として読み込まれていないか確認する |
| 二次確認 | net462 または netstandard2.0 の資産として Microsoft.AspNetCore.DataProtection 10.0.0〜10.0.6を利用しているアプリやライブラリ | .NET Frameworkアプリ、netstandard2.0 ライブラリ、古いターゲットフレームワークを持つ共通ライブラリを確認する |
| 原則として対象外 | Microsoft.AspNetCore.DataProtection 8.0.xまたは9.0.xを使う環境 | Microsoftのアドバイザリでは、問題のコードパスは10.0開発中に導入され、8.0/9.0のservicing branchにはバックポートされていないと説明されている |
| 原則として対象外 | 対象バージョンのパッケージを参照していない環境 | ただし、推移的依存関係と実行時にロードされたアセンブリは確認する |
注意したいのは、「Windowsだから絶対に関係ない」と短絡しないことです。アドバイザリでは、主要な影響構成ではWindows実行環境は対象外として説明されていますが、net462 や netstandard2.0 の資産を使う二次的な構成では、Windows例外がそのまま当てはまらないケースが示されています。(GitHub)
影響調査の進め方
セキュリティ更新の初動では、まず「どのアプリが影響を受ける可能性があるか」を短時間で切り分ける必要があります。開発チームだけに任せるのではなく、Security Admin、Identityチーム、SRE、Compliance担当が同じリストを見ながら進めると判断が速くなります。
パッケージ参照を確認する
リポジトリ単位では、csproj、Directory.Packages.props、packages.lock.json を確認します。Central Package Managementを使っている場合、個別のプロジェクトファイルではなく Directory.Packages.props にバージョンが集約されていることがあります。
Linux/macOSでは、次のように検索できます。
grep -R "Microsoft.AspNetCore.DataProtection" .ripgrepを使える環境なら、対象ファイルを絞ると見落としを減らせます。
rg "Microsoft\.AspNetCore\.DataProtection" -g "*.csproj" -g "Directory.Packages.props" -g "packages.lock.json"Windows PowerShellでは、次のように確認できます。
Get-ChildItem -Recurse -Include *.csproj,Directory.Packages.props,packages.lock.json |
Select-String "Microsoft.AspNetCore.DataProtection"直接参照がなくても、推移的依存関係で読み込まれている可能性があります。アプリのプロジェクトディレクトリで次のコマンドを実行します。
dotnet list package --include-transitiveData Protection関連だけを絞り込む場合は、Linux/macOSなら次のように確認できます。
dotnet list package --include-transitive | grep -i DataProtectionWindowsでは次のように確認できます。
dotnet list package --include-transitive | findstr /I DataProtection実行環境のバージョンを確認する
Microsoftは、.NET 10.0.7 SDKまたはRuntimeをインストールし、dotnet --info で10.0.7であることを確認したうえで、更新済みイメージやパッケージを使って再ビルド・再デプロイする手順を示しています。(Microsoft for Developers)
dotnet --infoCI/CDのビルドエージェントだけを更新しても、本番サーバーやコンテナイメージ内のランタイムが古いままでは意味がありません。次の3か所を分けて確認してください。
| 確認場所 | 見るべき内容 | よくある見落とし |
|---|---|---|
| 開発・ビルド環境 | SDKのバージョン | ビルドエージェントだけ10.0.7になり、本番ランタイムが古い |
| 本番ホスト | Runtime、ASP.NET Core Runtimeのバージョン | ホストOS上のランタイム更新が未実施 |
| コンテナ | ベースイメージ、アプリイメージ内のランタイム | DockerfileやCIキャッシュが古いイメージを使い続ける |
.NET 10.0のダウンロードページでは、.NET Runtime 10.0.7、ASP.NET Core Runtime 10.0.7、.NET Desktop Runtime 10.0.7が含まれることが確認できます。SDKとしては10.0.203や10.0.107が案内されており、これらには10.0.7のランタイムが含まれます。(Microsoft)
10.0.7への更新手順
基本方針は、対象パッケージ、SDK/Runtime、コンテナイメージを10.0.7系へそろえ、再ビルドしてデプロイすることです。
NuGetパッケージを更新する
Microsoft.AspNetCore.DataProtection を直接参照している場合は、10.0.7 へ更新します。NuGet Galleryでは、次の .NET CLI コマンドやPackageReference例が案内されています。([NuGet][6])
dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.7プロジェクトファイルで管理している場合は、次のように更新します。
<PackageReference Include="Microsoft.AspNetCore.DataProtection" Version="10.0.7" />Central Package Managementを使っている場合は、Directory.Packages.props 側を更新します。
<PackageVersion Include="Microsoft.AspNetCore.DataProtection" Version="10.0.7" />Data Protection拡張パッケージを使っている場合は、関連パッケージも同じ更新単位で確認してください。たとえば、Redis、Entity Framework Core、Azure Storage、Azure Key Vaultを使ってキー管理を行っている場合、Microsoft.AspNetCore.DataProtection.* 系のパッケージが複数含まれることがあります。
SDKとRuntimeを更新する
アプリをビルドする環境ではSDKを、アプリを実行する環境ではRuntimeまたはASP.NET Core Runtimeを更新します。Windows Server上でIISホスティングを行っている場合は、ASP.NET Core Hosting Bundleの更新も確認対象です。
更新後は、対象サーバーまたはコンテナ内で次を確認します。
dotnet --infoアプリが自己完結型デプロイ、framework-dependentデプロイ、コンテナデプロイのどれなのかによって確認ポイントが変わります。
| デプロイ方式 | 更新対象 | 確認ポイント |
|---|---|---|
| framework-dependent | ホスト側Runtime、ASP.NET Core Runtime | 本番ホストの dotnet --info が10.0.7系を示すか |
| self-contained | アプリ成果物に含まれるRuntime | 再発行して古いRuntimeを含んでいないか |
| コンテナ | ベースイメージ、アプリイメージ | docker pull だけでなく、アプリイメージを再ビルドしたか |
| Kubernetes | コンテナイメージ、Pod再作成 | 古いPodが残っていないか、digest固定で古いイメージを使っていないか |
更新後に動作確認する
今回の更新では、認証・復号・Data Protection周辺の挙動確認が重要です。単にアプリが起動するかだけでは不十分です。
最低限、次の観点をテストしてください。
| テスト項目 | 確認内容 |
|---|---|
| ログイン | 通常ユーザー、管理者ユーザーがログインできるか |
| ログアウト | セッション破棄後に再アクセスできないか |
| Cookie認証 | 既存Cookieの扱い、更新後の再ログイン挙動 |
| OIDC/OAuth | 外部IdPログイン、state検証、リダイレクト後の認証 |
| Antiforgery | POSTフォーム、管理画面、APIでCSRF対策が正常に動くか |
| TempData | リダイレクト後メッセージなどが壊れていないか |
| スケールアウト | 複数インスタンス間でCookie復号やキー共有に問題がないか |
とくにWebファームや複数Pod構成では、Data Protectionキーリングの共有設定が重要です。Microsoft Learnでは、Webファームの既定構成では各ノードに固有のキーリングが保存され、別ノードで暗号化されたデータを復号できないため、既定構成は一般にWebファームに適さないと説明されています。(Microsoft Learn)
影響環境ではキーリングローテーションを検討する
今回の対応で重要なのは、10.0.7 への更新だけでは一部リスクが残る可能性がある点です。Microsoftのアドバイザリでは、攻撃者が脆弱な期間に偽造ペイロードを使って特権ユーザーとして認証し、アプリに正規署名済みトークンを発行させていた場合、それらのトークンは 10.0.7 へ更新した後もData Protectionキーリングをローテーションしない限り有効なまま残る可能性があると説明されています。(GitHub)
キーリングローテーションが必要になりやすいケース
| 状況 | 判断 |
|---|---|
| 対象バージョンを使っていた | まず影響調査の対象にする |
| インターネット公開エンドポイントがあった | キーリングローテーションを強く検討する |
| 認証CookieやAntiforgery tokenを使っている | Identityチームと影響を確認する |
| リフレッシュトークン、APIキー、パスワードリセットリンクを発行している | アプリ層での失効・再発行も検討する |
| 社内限定でアクセス制限が強い | リスク評価を記録し、必要に応じて限定的な対応にする |
キーリングをローテーションすると、既存の認証Cookieや保護済みデータが使えなくなる可能性があります。Microsoftのアドバイザリでも、RevokeAllKeys により既存キーが失効し、新しいキーが次回のprotect操作で自動生成され、ユーザーは再サインインが必要になり、Antiforgery tokenも再発行されると説明されています。(GitHub)
実行例は環境により異なりますが、考え方としては「同じキーリングにアクセスできるアプリまたは管理用処理から、既存キーを失効させる」ことです。
using Microsoft.AspNetCore.DataProtection.KeyManagement;
var keyManager = serviceProvider.GetRequiredService<IKeyManager>();
keyManager.RevokeAllKeys(
revocationDate: DateTimeOffset.UtcNow,
reason: "CVE-2026-40372 mitigation");本番で実行する前に、次の点を必ず確認してください。
- どのキーリングを対象にするか
- 複数インスタンスが同じキーリングを参照しているか
- ユーザーの再ログインが許容される時間帯か
- 管理者アカウントがロックアウトされないか
- 古いトークンをアプリ層でどう扱うか
- 実行ログと変更管理チケットを残すか
Dockerコンテナで運用している場合、Microsoft LearnではData ProtectionキーをDocker volumeまたはAzure Key Vault、Redisなどの外部プロバイダーに永続化することが推奨されています。キーリングの場所を把握せずにローテーションすると、対象外のキーだけを操作したり、逆に想定外の環境へ影響したりする可能性があります。(Microsoft Learn)
トークン・ログ・長期的な資格情報の監査ポイント
10.0.7 へ更新してキーリングをローテーションしても、すべてのリスクが自動的に消えるとは限りません。Microsoftのアドバイザリでは、脆弱な期間に作成されたアプリケーションレベルの長期的な成果物、たとえばAPIキー、リフレッシュトークン、アクセストークン、パスワードリセットリンク、メール確認トークンなどを監査するよう推奨しています。(GitHub)
監査すべき対象
| 対象 | 確認内容 | 対応例 |
|---|---|---|
| セッション・リフレッシュトークン | 脆弱な期間に発行されたものが残っていないか | 全体失効、ユーザー単位失効、再認証要求 |
| APIキー | 認証済みリクエスト経由で発行されたキーがないか | 該当期間のキー再発行、利用ログ確認 |
| パスワードリセットリンク | 有効期限内のリンクが残っていないか | 該当期間のリンク無効化 |
| メール確認トークン | 未使用の確認トークンが残っていないか | 再発行または無効化 |
| 保護済みペイロード内の機密情報 | IDataProtector.Protect 出力に長期的な秘密情報を入れていないか | 元のシークレットをローテーション |
| Webサーバーログ | Cookie、query parameter、state値が大量に変化する高頻度アクセスがないか | SIEMで相関分析、IP・User-Agent・対象エンドポイントを確認 |
アドバイザリでは、保護済みペイロード内にデータベース接続文字列やサードパーティAPIキーなどの長期的なシークレットを格納している場合、それらを潜在的に漏えいしたものとして扱い、各発行元でローテーションすることも推奨されています。(GitHub)
役割別に見る実務対応
今回の更新は、開発チームだけで完結しにくい内容です。セキュリティ、ID管理、監査・コンプライアンスの各担当が、同じ事実に基づいて役割分担する必要があります。
| 役割 | まず行うこと | 残すべき証跡 |
|---|---|---|
| Security Admin | 対象アプリの棚卸し、インターネット公開有無、ログ調査方針の決定 | 影響範囲リスト、対応優先度、ログ調査結果 |
| Identityチーム | 認証Cookie、セッション、OIDC、リフレッシュトークン、パスワードリセットフローの確認 | 失効・再認証・キーリングローテーションの判断記録 |
| Complianceチーム | 更新適用状況とリスク評価の記録 | 変更管理チケット、適用日時、例外承認、再発防止メモ |
| 開発チーム | NuGet更新、再ビルド、認証・CSRF・TempDataのテスト | PR、ビルドログ、テスト結果 |
| SRE/運用チーム | Runtime、コンテナ、Pod、ホストの更新とロールアウト | デプロイログ、dotnet --info、イメージdigest |
グローバルにサービスを運用している場合は、地域ごとのメンテナンス時間帯、ログ保持期間、個人情報・セッション情報の扱い、利用者への再ログイン通知も考慮してください。とくにB2B SaaSでは、突然のセッション失効が顧客の監査や業務フローに影響することがあります。
失敗しやすいポイント
NuGetだけ更新してRuntimeを更新していない
Microsoft.AspNetCore.DataProtection を10.0.7へ上げても、実行環境のASP.NET Core Runtimeやコンテナイメージが古いままでは、期待した状態にならないことがあります。ビルド環境、実行環境、コンテナイメージを分けて確認してください。
直接参照だけを見て推移的依存関係を見落とす
Data Protectionは、Redis、Azure Storage、Entity Framework Coreなどの拡張パッケージ経由で使われることがあります。csproj に Microsoft.AspNetCore.DataProtection が直接書かれていなくても、dotnet list package --include-transitive で確認する必要があります。
「更新済み」だけでキーリングを見ない
影響を受けたアプリが外部公開されていた場合、更新後も脆弱な期間に発行された正規署名済みトークンが残る可能性があります。アドバイザリは、影響環境でインターネット公開エンドポイントを提供していた場合、Data Protectionキーリングのローテーションを推奨しています。(GitHub)
キーを削除してしまう
Data Protectionのキーは、単純に削除すればよいものではありません。Microsoft Learnでは、キーを削除すると保護されたデータが永久にアクセス不能になるため、キー削除は推奨されないと説明されています。今回のような対応では、削除ではなく失効・ローテーションの設計として扱うべきです。(Microsoft Learn)
本番ローテーションの影響を周知しない
キーリングローテーションにより、ユーザーの再ログイン、フォーム再送信、Antiforgery token再発行が発生する可能性があります。社内システムならヘルプデスク、外部向けSaaSならカスタマーサポートやステータスページ担当にも事前共有が必要です。
よくある質問
.NET 8や.NET 9のData Protectionも対象ですか？
Microsoftのアドバイザリでは、Microsoft.AspNetCore.DataProtection 8.0.xまたは9.0.xを使う環境は対象外として説明されています。問題のコードパスは10.0開発中に導入され、8.0または9.0のservicing branchにはバックポートされていないとされています。(GitHub)
Windows Server上のASP.NET Coreアプリは対応不要ですか？
主要な影響構成では、Windowsで実行されているアプリは対象外と説明されています。ただし、net462 や netstandard2.0 の資産として Microsoft.AspNetCore.DataProtection 10.0.0〜10.0.6を使う二次的な構成では、Windows例外が当てはまらないケースがあります。Windowsかどうかだけで判断せず、パッケージバージョン、ターゲットフレームワーク、実行時に読み込まれる資産を確認してください。(GitHub)
10.0.7に更新すればキーリングローテーションは不要ですか？
影響を受けておらず、インターネット公開もしていない環境では、更新と確認で十分な場合があります。一方、影響環境で外部公開エンドポイントを運用していた場合は、キーリングローテーションと長期トークンの監査を検討すべきです。アドバイザリでは、脆弱な期間に発行された正規署名済みトークンは、10.0.7へ更新した後もキーリングをローテーションしない限り有効なまま残る可能性があると説明されています。(GitHub)
10.0.6で発生していた復号エラーと今回の脆弱性は関係ありますか？
Microsoftのブログでは、.NET 10.0.6リリース後に一部顧客から復号失敗が報告され、その調査の中で回帰が脆弱性も露出させていることが判明したと説明されています。つまり、復号エラーの修正だけでなく、セキュリティ上の問題に対応する更新として扱う必要があります。(Microsoft for Developers)
まとめ：次に取るべき行動
.NET 10.0.7 out-of-band security updateは、ASP.NET Core Data Protectionを利用するアプリの認証・トークン・暗号化データに関わる重要な更新です。最初にやるべきことは、対象パッケージの有無を確認し、10.0.7 へ更新し、再ビルド・再デプロイ・dotnet --info による確認を完了することです。
そのうえで、次の順に対応してください。
Microsoft.AspNetCore.DataProtection10.0.0〜10.0.6の利用有無を確認する- 直接参照だけでなく、推移的依存関係も確認する
- SDK、Runtime、ASP.NET Core Runtime、コンテナイメージを10.0.7系へ更新する
- 認証、OIDC、Antiforgery、TempData、スケールアウト構成をテストする
- 影響環境で外部公開していた場合は、Data Protectionキーリングローテーションを検討する
- リフレッシュトークン、APIキー、パスワードリセットリンクなどの長期的な資格情報を監査する
- 変更管理チケット、更新日時、対象外判断、ログ調査結果を証跡として残す
今回の更新は、パッチ適用だけでなく「脆弱な期間に何が発行された可能性があるか」まで見ることが重要です。Security Admin、Identityチーム、Complianceチームが同じ影響範囲リストを共有し、更新・ローテーション・監査を一つの対応計画として進めることが、もっとも実務的な対応になります。
[6]: https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection “
NuGet Gallery
| Microsoft.AspNetCore.DataProtection 10.0.7
“
コメント