--- title: "CVE-2026-40372とは？.NET 10.0.7で修正されたASP.NET Core権限昇格の影響範囲と対応手順" url: "https://www.issoh.co.jp/tech/details/11891/" published: 2026-04-23 updated: 2026-10-02 categories: ["脆弱性・インシデント"] publisher: "株式会社一創" --- # CVE-2026-40372とは？.NET 10.0.7で修正されたASP.NET Core権限昇格の影響範囲と対応手順 2026年4月21日、Microsoftは月例のPatch Tuesdayを待たずに.NET 10.0.7を配信しました。修正対象のCVE-2026-40372は、ASP.NET Core Data Protectionが認証Cookieやトークンの改ざん検知に使うHMAC検証が機能せず、攻撃者が有効な認証ペイロードを偽造できるという欠陥です。CVSSは9.1。ただし「.NET 10を使っている＝危ない」ではありません。公式アドバイザリは被影響条件をかなり細かく絞り込んでおり、Web SDKで作った通常のASP.NET Coreアプリは既定で対象外になります。一方で「Windowsだから安全」という早合点は、一部の構成を判定から取りこぼす原因です。まず自社が当事者かを正確に切り分け、当事者ならパッチとキーリング再生成をセットで実施する——この記事はその順序で判断材料を示します。 ## まとめ：CVE-2026-40372で今すぐやること - **脆弱性**：ASP.NET Core Data Protectionの認証付き暗号化で、HMAC検証タグがペイロードの誤ったバイト列から計算され、しかも計算結果が破棄されていた。結果として偽造ペイロードが検証を通る（CVE-2026-40372 / CVSS 3.1 9.1 / CWE-347 / 深刻度Important）。 - **修正版**：.NET 10.0.7（ランタイム10.0.7、SDKは10.0.203または10.0.107）。2026年4月21日にOOBリリース。2026年10月2日時点の最新は**10.0.12**（2026年9月8日、SDKは10.0.401または10.0.112）で、10.0.8以降の月例でも計40件のCVEが直っているため、更新先は10.0.12が妥当。 - **対象**：Microsoft.AspNetCore.DataProtection 10.0.0〜10.0.6。ただし公式の被影響条件を満たす構成に限る。**Web SDKの通常のASP.NET Coreアプリは既定で対象外**。逆に**net462／netstandard2.0アセットを消費する構成はWindowsでも対象**。.NET 8.0.x / 9.0.x は非対象。 - **やること**：(1) 後述の条件で影響有無を判定 →(2) 10.0.7以上（推奨は10.0.12）へ更新し**NuGet参照ごと再ビルドして再デプロイ** →(3) 対象かつ脆弱期間に外部公開していたなら**DataProtectionキーリングを失効** →(4) DB内のAPIキーやリフレッシュトークンなど、キーリング失効が届かない長期資産を個別に無効化。 10.0.7を当てれば偽造ペイロード自体は拒否されます。それでも(3)(4)が要るのは、なりすまし中にアプリが_正規に_発行してしまったトークンが生き残るからです。以下、判定から対処までを順に見ていきます。 ## CVE-2026-40372の欠陥：HMAC検証タグの計算範囲の誤りと結果の破棄 Data ProtectionはASP.NET Coreの暗号化基盤で、認証Cookie、AntiForgeryトークン、OpenID ConnectのstateやTempDataなど、クライアントに渡して後で戻ってくるデータの保護に使われます。仕組みは認証付き暗号化——暗号化した上でHMACの検証タグを付け、復号前にタグを照合して改ざんを弾きます。この「照合」が壊れていたのが今回の欠陥です。 Microsoftの公式アドバイザリ（[dotnet/announcements #395](https://github.com/dotnet/announcements/issues/395)）は、managed authenticated encryptorが「HMAC検証タグをペイロードの誤ったバイト列に対して計算し、計算したハッシュを破棄していた」と説明しています。誤った範囲で計算した上に結果を捨てるため、改ざんの検知そのものが成立しません。CWE-347（暗号署名の不適切な検証）に分類されるのはこのためです。 CVSS 3.1のベクタは `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N`、スコア9.1。ネットワーク越しに、認証も利用者操作も不要で、機密性と完全性の両方に高い影響が出るという評価です（Microsoftの深刻度ラベル自体はImportant）。 ### 認証Cookieやトークンの偽造対象と保護済みペイロードの復号の理由 アドバイザリは、攻撃者がData Protectionの真正性チェックを通過するペイロードを偽造でき、加えて保護済みペイロードの一部を復号し得るとしています。復号まで成立するのは、検証が機能しない状態がパディングオラクル型の条件を作るためで、Microsoft自身がこれを2010年の**MS10-070**（ASP.NETの旧暗号基盤で同種のパディングオラクル攻撃が成立した事例）に匹敵する能力だと位置づけています。 実務上のリスクは、Data Protectionで守っているものすべてに及びます。 - 認証Cookie（管理者を含む任意ユーザーへのなりすまし） - AntiForgeryトークン（CSRF防御のバイパス） - OIDCのstate／nonceなど認証フロー中の一時データ - Data Protectionで保護して発行したパスワードリセットリンク・メール確認トークン なお、2026年10月1日版のCISA KEV（悪用が確認された脆弱性の一覧）に本件は載っておらず、公開PoCの報告も確認できませんでした。[NVDの登録](https://nvd.nist.gov/vuln/detail/CVE-2026-40372)でも、CNAのMicrosoftとCISA-ADPがともにCVSS 3.1で9.1と評価しています。とはいえ欠陥の性質上、悪用の難易度は高くないと見るべきです。 ## 自社構成への影響の有無：公式アドバイザリの被影響条件による判定 ここが今回のCVEで最も誤解が多い部分です。「バージョンが該当したら全部危ない」という読み方は誤りで、公式アドバイザリは**主構成（Primary）**と**副構成（Secondary）**を分けて条件を明示しています。順に判定してください。 ### 主構成の影響判定：NuGet参照・実行時ロード・OSの3条件の確認 アドバイザリのPrimary affected configurationは、次の3つを**すべて**満たす場合です。1つでも外れれば、この構成では対象外です。 - **条件1**：Microsoft.AspNetCore.DataProtection 10.0.6 をNuGetから参照している（直接参照のほか、`.StackExchangeRedis`、`.EntityFrameworkCore`、`.AzureKeyVault`、`.AzureStorage` などを経由した推移的参照を含む） - **条件2**：その10.0.6のNuGetバイナリが**実行時に実際にロードされる** - **条件3**：Linux・macOSなど**非Windows**のOSで動作している 参照の有無は推移的依存まで含めて確認します。 ``` # Linux / macOS dotnet list package --include-transitive | grep -i DataProtection # Windows (PowerShell) dotnet list package --include-transitive | findstr /I DataProtection ``` アドバイザリの被影響パッケージ表は 10.0.0〜10.0.6 を対象としています。主構成の記述は10.0.6を名指ししていますが、この範囲に入るなら対象候補として判定を進めるのが安全です。 ### 条件2の判定：PrunePackageReferenceによるNuGet版の除外 見落としやすく、そして直感と逆なのが条件2です。アドバイザリは、欠陥入りのNuGetバイナリが実行時にロードされるのは**アプリが `Microsoft.NET.Sdk.Web` をターゲットしておらず、かつ `Microsoft.AspNetCore.App` の FrameworkReference も直接・推移的に持たない場合**だと説明しています。加えて、**.NET 10で既定有効の `PrunePackageReference` をオプトアウトしている場合**も同様です。 裏返すと、**Web SDK（`Microsoft.NET.Sdk.Web`）で作った標準的なASP.NET Core Webアプリは、PrunePackageReferenceがNuGet版を既定で刈り取り、共有フレームワーク側の正しいアセンブリを使うため、既定では対象外**ということです。「LinuxコンテナでASP.NET Coreを動かしているから危ない」という直感は、この条件では成立しません。 実際に当事者になりやすいのは、次のような構成です。 - Web SDKを使わないコンソールアプリ・ワーカーサービス・クラスライブラリからDataProtectionを参照している（Webアプリ本体より、キーリングを共有する裏側のバッチやワーカーの方が該当しやすい） - `PrunePackageReference` を明示的に無効化している - フレームワーク依存だが、インストール済み共有フレームワークのバージョンがPackageReferenceのバージョンを下回る（アドバイザリの例：共有フレームワーク10.0.5＋PackageReference 10.0.6は**対象**／共有フレームワーク10.0.6＋PackageReference 10.0.6は対象外） したがって判定で最初に開くべきは `dotnet --info` ではなく `.csproj` です。`` になっているか、`PrunePackageReference` を切っていないか、この2点を確認してください。 ### Windowsも対象：net462／netstandard2.0のアセット消費 欠陥があるのは_managed_ authenticated encryptorです。Windows上のASP.NET Core（net10.0ターゲット）は既定でWindowsのCNGベースの実装を使うため、この欠陥のあるコードパスを通りません。ここまでは「Windowsは対象外」で正しい。 **ただし、公式アドバイザリにはWindows例外が適用されない副構成があります。**DataProtection 10.0.0〜10.0.6 を参照し、ビルドが `net462` または `netstandard2.0` のターゲットフレームワークアセットを消費している場合です。これは、アプリが `net10.0` をターゲットせずに10.0系パッケージを引いたとき（`net8.0`、`net9.0`、`net481` など）に起こります。 この構成では**CNGパスがnet10.0アセットにしか存在しないため、OSを問わずmanaged実装を通ります。つまりWindows上でも影響を受ける構成です**。アドバイザリはこの母集団を「はるかに小さい」とし、主に次の2種類だと述べています。 - ASP.NET Core DataProtectionパッケージをたまたま使っている.NET Framework製のデスクトップ／サーバーアプリ - `netstandard2.0` をターゲットとし、10.0系のDataProtectionパッケージを参照しているライブラリ ### 構成別の判定早見表：OS・参照元・アセットによる対象と対象外の切り分け 表中のWebはASP.NET Core、DPはDataProtection、FWは共有フレームワーク、PRはPackageReference、FRはFrameworkReferenceの略記です。「刈り取り」はPrunePackageReferenceによるNuGet版の除外を指します。非Web SDKの行はコンソール・ワーカー・ライブラリからの参照、最終行はOSを問わずnet462またはnetstandard2.0アセットを消費する構成です。最終行ではWindowsの対象外という扱いも適用されません。表のバージョンはFWとPRを別々に読み、実行時にロードされる側を確認してください。 | 構成 | 判定 | 理由 | | ----------------------- | ------ | ----------------------- | | Windows・Web（net10.0） | 対象外 | CNG実装を使い欠陥コードパスを通らない | | .NET 8.0.x／9.0.xのDP | 対象外 | 10.0開発時に混入・旧版への移植なし | | Web SDK・FWとPRは10.0.6 | 対象外 | 刈り取りでNuGet版を除外し共有FWを使用 | | Linux・FW10.0.5／PR10.0.6 | **対象** | 欠陥入りNuGetコピーが実行時にロードされる | | Linux・非Web SDKで参照 | **対象** | FRが無くNuGet版をロード | | net462／netstandard2.0 | **対象** | CNGなし・managed実装で全OSが対象 | 判定に迷う場合は「対象」と見なして更新する方が安全です。10.0.7への更新自体は破壊的変更を伴わず、コストは低く済みます。 ## .NET 10.0.7への更新手順とSDK・ランタイムの選択基準 2026年4月21日リリースの.NET 10.0.7が修正版です。ランタイムは10.0.7、SDKは**10.0.203（10.0.2xx帯）**と**10.0.107（10.0.1xx帯）**の2本が同時に出ています。どちらも同じ10.0.7ランタイムを含むので、いま使っているSDK帯に合わせて選べば構いません。global.jsonでSDKを固定しているプロジェクトは、そこに書かれた帯に合わせる必要があります。 ただし10.0.7は「この脆弱性を直した最初の版」です。[.NET 10のリリース情報（releases.json）](https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/10.0/releases.json)によると、その後も10.0.8（5月）から10.0.12（9月8日）まで毎月セキュリティ修正が出ており、2026年10月2日時点の最新は10.0.12（SDKは10.0.401と10.0.112）です。いまから更新するなら10.0.12へ上げてください。 ### Linuxサーバ・Dockerイメージの更新方法と修正版タグの指定 パッケージマネージャ経由なら通常のアップグレードで入ります。 ``` sudo apt-get update sudo apt-get install -y dotnet-sdk-10.0 aspnetcore-runtime-10.0 dotnet --list-runtimes ``` コンテナはベースイメージのタグを修正版以上へ上げてイメージを再ビルドします。`10.0` のような可変タグを使っていても、ローカルやレジストリのキャッシュで古い層が残ることがあるため、明示タグで固定してから再ビルドするのが確実です。 ``` # ランタイムイメージはランタイムの版、SDK イメージは SDK の版でタグが付く FROM mcr.microsoft.com/dotnet/sdk:10.0.401 AS build FROM mcr.microsoft.com/dotnet/aspnet:10.0.12 AS runtime ``` 旧版の本記事は `sdk:10.0.7` と書いていましたが、SDKイメージにこのタグはありません（MCRのタグ一覧で確認）。10.0.7の時点で揃えるなら `sdk:10.0.203` と `aspnet:10.0.7` の組み合わせです。 ### よくある更新失敗：ランタイム更新後のNuGet参照と再ビルドの漏れ 条件2の裏返しで、**ホストのランタイムを10.0.7に上げただけでは、NuGetのDataProtectionを実行時にロードする構成のアプリは脆弱なまま**です。PackageReferenceのバージョンを10.0.7以上に更新し、restore・build・publishをやり直して再デプロイするところまでが1セットです。 ``` dotnet add package Microsoft.AspNetCore.DataProtection --version 10.0.12 dotnet restore --force dotnet publish -c Release ``` デプロイ後は再度 `dotnet list package --include-transitive` で、推移的に引かれた10.0.6が残っていないか、実際に載っているバージョンが10.0.7になっているかを確認してください。「更新したつもり」で終わっている事故が、この脆弱性で最も起きやすいパターンです。 ## パッチだけでは終わらない：DataProtectionキーリングの再生成 ここが今回の対応で最も判断を要する部分です。10.0.7を適用すると、脆弱期間に作られた**偽造ペイロード自体は拒否されます**。偽造されたペイロードは必然的にHMACバイトが全ゼロになるため、修正後の検証ルーチンが弾くからです。 問題はその先にあります。攻撃者が偽造Cookieで特権ユーザーになりすましている間に、アプリケーションが**正規に署名して発行してしまった**トークン——セッションリフレッシュトークン、APIキー、パスワードリセットリンクなど——は、暗号学的には何ら不正ではありません。したがって**10.0.7へのアップグレードでは無効化されず、有効期限まで通り続けます**。これを断ち切るには、DataProtectionのキーリングを失効させて信頼の起点を作り直す必要があります。 ### RevokeAllKeysによる一括失効と、全ユーザー強制ログアウトという代償 既存キーの一括失効は `IKeyManager` で行います。アドバイザリのサンプルは、同じキーリングにアクセスできるアプリから一度だけ実行する想定です。 ``` var services = new ServiceCollection() .AddDataProtection() // 既存のリポジトリ・保護設定をここに再現する .Services .BuildServiceProvider(); var keyManager = services.GetRequiredService(); keyManager.RevokeAllKeys( // リング内の全キーを失効させる。範囲を絞るなら10.0.6デプロイ直前の時刻を指定する revocationDate: DateTimeOffset.UtcNow, reason: "Emergency revocation after CVE-2026-40372 remediation"); ``` `RevokeAllKeys` はキーリング内の全キーを失効済みとしてマークし、次のprotect操作で新しいキーが自動生成されます。副作用として**全ユーザーが再ログインを求められ、発行済みAntiForgeryトークンもすべて再発行になります**。これは想定された効果そのものです。裏を返せば「誰にも気づかれずに対応を終えた」なら、キーリングが回っていない可能性を疑うべきです。 影響を絞れるなら、より外科的な手段もあります。ある時刻Tより古いキーは脆弱なプロセスで使われていないと確証が持てる場合、`RevokeKey(Guid keyId, string reason)` で脆弱期間に有効だったキーだけを失効させられます。全ユーザーのログアウトを避けたいなら、まずこちらを検討してください。 実施タイミングは10.0.7のデプロイ完了後です。複数インスタンスでキーリングを共有している構成（Redisやblobストレージに永続化しているケース）では、全インスタンスが10.0.7で動いていることを確認してから失効させないと、更新の遅れたインスタンスが新しいキーを扱えず障害になります。 ### キーリング失効が届かない長期資産の判別と発行済みトークンの個別無効化 キーリングの失効は、Data Protectionが保護しているペイロードにしか効きません。アプリケーションが自前でデータベースに保存している資産には届かないため、脆弱期間中に発行されたものは別途無効化が要ります。 - DBに永続化しているリフレッシュトークン・アクセストークン・セッションレコード - 保護されたエンドポイント経由で発行したAPIキー - 脆弱期間に送信され、まだ期限切れになっていないパスワードリセットリンク・メール確認トークン - 保護ペイロード内に格納していた接続文字列・外部サービスのシークレット（漏洩したものとして発行元でローテーション） 逆に、**認証エンドポイント経由でこうした長期資産を発行していないアプリなら、キーリングの失効だけで十分**だとアドバイザリは明言しています。対応範囲は闇雲に広げず、ここで確定させてください。 主構成・副構成の判定や、キーリング失効の影響範囲を自社だけで決めきれない場合は、第三者の診断で確かめる方法もあります。一創の[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)では、ASP.NET Coreを含むWebアプリケーションの認証・セッション管理を診断しています。 そもそもキーリングを回すべきかの判断基準は、**脆弱期間中にインターネットへ公開されていたか**の一点です。閉域網の検証環境まで全ログアウトさせる必要はありません。逆に公開エンドポイントを持つ本番環境は、悪用の痕跡が見つかっていなくても回すのが妥当です。偽造の成功はサーバ側のログに正常な認証として記録されるため、「痕跡がない＝安全」とは言えません。 それでもログを当たるなら、保護ペイロード（認証Cookie、AntiForgeryトークン、stateパラメータ）を受け付けるエンドポイントへの**異常なリクエスト量**を脆弱期間で確認します。パディングオラクル攻撃は1バイト復元するのに多数の試行を要し、通常トラフィックとは桁が違うためです。単一の認証エンドポイントに、値を変えたCookieやクエリパラメータで大量アクセスが継続していれば強い兆候です。 ## 10.0.6の復号失敗バグの調査からOOBリリースに至った経緯 今回のリリースが月例サイクルの外に出た理由は、発見の経路にあります。2026年4月14日のPatch Tuesdayで配信された.NET 10.0.6の適用後、「アプリケーションで復号が失敗する」という報告が4月16日にユーザーから寄せられました（[aspnetcore issue #66335](https://github.com/dotnet/aspnetcore/issues/66335)「CRITICAL BREAKING CHANGE in Microsoft.AspNetCore.DataProtection from 10.0.5 => 10.0.6」）。Microsoftがこの回帰バグを調査する過程で、同じコード変更がセキュリティ上の欠陥も生んでいたことが判明します。 つまり**可用性の不具合（復号できない）の裏に、より深刻な完全性の欠陥（検証が機能しない）が隠れていた**という構図です。次のPatch Tuesdayまで待てば1か月近く脆弱な状態が続くため、Microsoftは10.0.6のリリースから約1週間後の4月21日に10.0.7をOOB配信しました。 運用側の教訓は明確です。10.0.6を当てたあとに復号エラーが出て「相性問題」としてロールバックした環境は、10.0.6以前の脆弱なバージョンに留まっている可能性があります。そうした環境こそ優先的に10.0.7へ上げてください。定例パッチ適用後の異常は、単なる不具合ではなくセキュリティ告知の予兆であり得ます（[Apache HTTP Server 2.4の脆弱性対応](https://www.issoh.co.jp/tech/details/12051/)や[Node.jsの脆弱性対応](https://www.issoh.co.jp/tech/details/10243/)でも、まず影響条件の切り分けから入るのが定石です）。 ## よくある質問 ### .NET 10.0.7はどこから入手できますか？ Microsoftの公式ダウンロードページ、またはLinuxのパッケージマネージャ（`dotnet-sdk-10.0` / `aspnetcore-runtime-10.0`）から入手できます。SDKは10.0.203と10.0.107の2本があり、どちらもランタイム10.0.7を含みます。global.jsonでSDK帯を固定している場合は、その帯に合う方を選んでください。2026年10月2日時点では、その後の月例修正を含む10.0.12（SDK 10.0.401／10.0.112）が[公式ダウンロードページ](https://dotnet.microsoft.com/en-us/download/dotnet/10.0)の最新です。 ### Windowsサーバで運用していますが影響を受けますか？ 原則として受けません。欠陥があるのはmanaged authenticated encryptorで、Windows上のASP.NET Core（net10.0ターゲット）は既定でCNGベースの実装を使うため該当コードパスを通りません。ただし例外があります。アプリやライブラリが `net462` または `netstandard2.0` のアセットとしてDataProtection 10.0.0〜10.0.6を消費している場合、CNGパスが存在せずmanaged実装を通るため**Windows上でも影響を受けます**。.NET Framework製アプリやnetstandard2.0ライブラリでDataProtectionを参照しているなら、Windowsでも対象と考えて更新してください。 ### .NET 8や.NET 9は影響を受けますか？ 受けません。問題のコードは.NET 10の開発中に入ったもので、8.0.xおよび9.0.xのサービシングブランチにはバックポートされていません。ターゲットフレームワーク・OS・共有フレームワークのバージョンを問わず対象外です。ただし、これらのアプリが10.0系のDataProtectionパッケージを参照している場合は前述の副構成に該当し得るので、参照バージョンを確認してください。 ### 公式アドバイザリはどこで確認できますか？ GitHubの `dotnet/announcements` リポジトリのissue #395がMicrosoftのセキュリティアドバイザリ本体で、被影響条件と対応手順が記載されています。議論はaspnetcoreリポジトリの[issue #66410](https://github.com/dotnet/aspnetcore/issues/66410)が議論の場です。あわせて.NET Blogの「.NET 10.0.7 Out-of-Band Security Update」に更新手順がまとまっています。判定は必ず一次情報で最終確認してください。 ### キーリングを再生成するとユーザーはログアウトされますか？ `RevokeAllKeys` を使えばされます。既存キーがすべて失効し、そのキーで保護された認証Cookieは拒否されるため、全ユーザーの再ログインが必要です。脆弱期間に有効だったキーを特定できるなら、`RevokeKey(Guid keyId, string reason)` で該当キーだけを失効させることで影響範囲を狭められます。いずれの場合も事前にメンテナンス告知を出したうえで実施してください。 ## 関連記事 - [.NET 10 LTSリリースの概要：3年間長期サポートとなる注目の新機能を徹底解説](https://www.issoh.co.jp/tech/details/9954/) - [.NET 11の新機能・リリース日・ロードマップ総まとめ｜C# 15とRuntime Async、.NET 10との違い](https://www.issoh.co.jp/tech/details/11045/) - [Apache HTTP Server 2.4の脆弱性まとめ：CVE-2026-33523ほか2.4.67/2.4.68の影響範囲と対応手順](https://www.issoh.co.jp/tech/details/12051/) - [CVE-2026-31431「Copy Fail」とは？影響範囲と今すぐ行うべきパッチ・緩和策をわかりやすく解説](https://www.issoh.co.jp/tech/details/11972/) - [Node.jsの脆弱性とは｜影響の確認方法と対応バージョン・アップデート手順【2026年6月最新】](https://www.issoh.co.jp/tech/details/10243/) --- 出典: [CVE-2026-40372とは？.NET 10.0.7で修正されたASP.NET Core権限昇格の影響範囲と対応手順]()（株式会社一創）