ASP.NET Coreの認証テンプレートに脆弱性｜更新後も生成済みコードの修正が必要

MicrosoftはASP.NET Core Identityのコード生成テンプレートについて、パスワード再設定やメール確認の送信先を誤る脆弱性CVE-2026-118741を公表しました。対象テンプレートで認証機能を生成した開発者は、生成ツールや依存パッケージを更新するだけでなく、既存アプリのハンドラーを修正し、再ビルド・再配備する必要があります。ランタイム更新だけでは生成済みコードは直りません。

問題は、アカウントに保存されたメールアドレスではなく、要求で渡されたメールアドレスを再設定・確認メッセージの宛先に使うことです。Microsoftの公式勧告に基づき、11月12日時点で確認した更新先と修正手順を整理します。対象OSやCPUの種類で除外される問題ではなく、どの生成元を使い、どのコードが配備されているかが判断の中心です。

メールの検索入力と送信先を分ける

公式の深刻度はHigh、CVSS 3.1基本値は8.1、分類はCWE-640です。ベクトルはネットワーク経由、認証不要、利用者操作不要ですが、攻撃複雑性はHighと評価されています。認証不要という一部分だけで、任意の入力から必ず他人のアカウントを取得できるとまで広げて説明することはできません。

修正の要点は、利用者を検索するための入力値と、秘密を含むメッセージを届ける宛先を別の値として扱うことです。Input.Emailはアカウントの検索に残し、送信時には検索で見つかったアカウントから保存済みアドレスを取得します。入力値の形式が正しいことだけでは、宛先が当該アカウントに結び付くことを保証できません。

公式勧告の改訂履歴は初回公表を2026年11月10日としています。案内用のGitHub Issueが11月11日に作られたこととは区別してください。本稿で確認した一次資料は実環境での悪用を確定していないため、悪用中や被害発生とは表現しません。

生成元の更新と既存アプリの修正は別の作業

テンプレートから生成されたソースは、生成ツールを更新しても自動的に置き換わりません。開発端末を最新にして次の生成を安全にする作業と、すでにリポジトリへ取り込まれて本番で動く処理を直す作業を、それぞれ完了させる必要があります。

確認対象はForgotPasswordとResendEmailConfirmationのハンドラーです。Blazorの対応する処理も対象に含みます。独自の認証画面へ変更している場合は、元テンプレートのファイル名が残っているかだけでなく、再設定・確認メールの送信にどの値を渡すかを確認してください。

本サイトの提案として、サービス名、生成時のSDK・ツール・パッケージ、該当ハンドラー、現在のメール宛先、修正コミット、本番反映先を一枚の作業票にまとめます。生成履歴が不明でも、現在の送信コードを確認する作業を後回しにしないでください。

MVCとDesignはプロジェクト内の解決版を確認

Microsoft.VisualStudio.Web.CodeGenerators.Mvcが問題のテンプレートを含みます。Microsoft.VisualStudio.Web.CodeGeneration.Designは、MVC生成パッケージを最小バージョン依存として取り込む親パッケージです。以下は安定版の範囲です。

対象	影響する安定版	修正版・対応
Mvc／Design 8系	8.0.0～8.0.23	8.0.24
Mvc／Design 9系	9.0.0～9.0.12	9.0.13
Mvc／Design 10系	10.0.0～10.0.2	10.0.3

Designの古い参照が残っていても、独立した指定によって修正済みのMVC生成パッケージを解決しているなら、そのDesign参照だけを根拠に脆弱とは判断できません。宣言された版と実際に復元・解決された依存関係を対応づけます。

dotnet-aspnet-codegeneratorはアプリの依存関係からジェネレーターを読み込みます。コマンドラインツールだけを更新してもプロジェクト側のパッケージが置き換わるとは限りません。複数リポジトリや共通の依存管理ファイルがある場合、生成元の変更が各プロジェクトに届くかも確認します。

dotnet newのテンプレートは別の版番号

Microsoft.DotNet.Web.ProjectTemplatesは、SDKに同梱される場合と別途インストールする場合があります。プロジェクトのPackageReferenceを見るだけでは、どのテンプレートで作られたかを特定できません。公式の確認コマンドは次のとおりです。作業ディレクトリ内で選ばれるSDKを確認します。

dotnet --version
dotnet new list
dotnet new uninstall

最後のコマンドは引数なしで、別途導入したテンプレートパッケージを一覧します。ここにパッケージ名を追加して削除を実行する手順ではありません。global.jsonが古いSDKを選び続けていないかも点検してください。SDK更新と、別途入れたテンプレートパックの更新は独立して扱います。

対象	影響する安定版	修正版・対応
ProjectTemplates.8.0	8.0.0～8.0.33	8.0.34
ProjectTemplates.9.0	9.0.0～9.0.22	9.0.23
ProjectTemplates.10.0	10.0.0～10.0.14	10.0.15

この表の版をMVCやDesignの更新先に流用しないでください。たとえば10系でも、MVC／Designの修正版は10.0.3、ProjectTemplatesは10.0.15です。同じ.NET向けの部品であっても、パッケージ名が違えば修正境界も違います。

scaffoldツールは20.3.0へ更新または移行

Microsoft.dotnet-scaffoldは10.0.0～10.0.2と、20.0.0-preview.1.26156.3～20.1.0が影響対象です。修正版は20.3.0です。旧Microsoft.dotnet-scaffold-aspnetの9.0.0～9.0.12は、新ツールへ移行します。20.3.0は.NET 8～11をサポートするツールで、プロジェクトへ追加するMVC／Designパッケージの版ではありません。

既存のグローバルMicrosoft.dotnet-scaffoldを更新する場合、公式は次を案内しています。新規導入ではupdateではなくinstallを使用します。

dotnet tool update --global Microsoft.dotnet-scaffold --version 20.3.0

旧Microsoft.dotnet-scaffold-aspnetを使用している場合の公式手順は、旧ツールの削除と置換先の導入です。ローカルツールでは--globalを--localに替え、ツールマニフェストのあるディレクトリで実行します。

dotnet tool uninstall --global Microsoft.dotnet-scaffold-aspnet
dotnet tool install --global Microsoft.dotnet-scaffold --version 20.3.0

Visual Studioは更新済みの生成ツールを自動的に導入・利用しますが、別途のCLI導入は個別更新が必要です。またVisual Studio 17.14は従来のCodeGenerationパッケージを使うため、IDEを更新したという記録だけで独立管理の依存関係まで確認済みとしないようにします。

プレビュー版は範囲を推測しない

勧告には安定版以外にも、影響する正確なプレビュー版・RC版が列挙されています。これらを一つの連続した範囲へまとめてはいけません。試験段階で生成した認証機能を本番へ持ち込んだ場合も、生成済みコードの確認が必要です。

たとえばMVC／Designの11.0.0-preview.1.26156.3と11.0.0-preview.1.26230.3、旧scaffold-aspnetの10.0.0-rc.1.25458.5と10.0.0-rc.1.25468.1も対象です。既存ハンドラーの手動修正は、ツールを移行しなければ実施できないわけではありません。今後の生成元には修正済みツールを選びます。

生成済みハンドラーの修正箇所

公式手順は、既存のユーザー検索、ユーザー不在時の応答、パスワード再設定の確認条件、トークン生成、コールバックURLのエンコードを維持するよう求めています。それらのユーザー検査の後、メールを送る前に保存済みの宛先を取得します。次は公式の挿入例です。

var storedEmail = await UserManager.GetEmailAsync(user);
if (string.IsNullOrEmpty(storedEmail))
{
    throw new InvalidOperationException("Users must have an email.");
}

Razor PagesではUserManagerを_userManagerへ読み替えます。送信先引数のInput.EmailだけをstoredEmailへ変更し、_emailSender.SendEmailAsync、EmailSender.SendPasswordResetLinkAsync、EmailSender.SendConfirmationLinkAsyncのうち該当する呼び出しへ適用します。アカウント検索用のInput.Emailまで一括置換する手順ではありません。

両ハンドラーとBlazorの対応箇所を修正した後、再ビルドして再配備します。古いテンプレートで再生成すれば修正が失われるため、その場合は手動修正も再適用します。生成物の差分レビューを保守手順へ含めることが、同じ問題を戻さないための確認になります。

本番反映と試験の完了条件

以下は公式修正を確認するための本サイトの提案で、当サイトが実行した実測ではありません。管理下の検証環境とテスト用アカウントを使い、メール送信を検証用の受信先へ隔離して確認します。第三者のアカウントや実利用者へ再設定メールを送る試験は不要です。

入力がユーザー検索に使われ、送信先は取得したユーザーの保存済みアドレスになることを、送信処理の引数や検証用メールで確認します。保存済みアドレスが空なら送信されないこと、ユーザー不在時などの従来の応答が保たれることも確認します。実環境に独自の正規化や認証ストアがある場合、その経路を含めて試験してください。

最後に、修正コミットから作った成果物がすべての稼働先へ届いたかを確認します。ツールの版が最新であること、生成ソースが修正済みであること、本番がその成果物で動くことは別々の証跡です。この三つをそろえて、今回の対応を完了と判断してください。