ASP.NET Core

ASP.NET Core、パッチが脆弱性を呼んだ緊急OOB

情報の灯台

2026年4月22日

4月のパッチチューズデーで配られた修正が、権限昇格の穴を開けていた。Microsoftが一週間後に緊急の帯域外更新を出した理由は、自らの修正が信頼の根幹に触れていたからだ。

パッチチューズデーが呼び込んだ権限昇格

Microsoftが2026年4月21日、ASP.NET Core向けに緊急の帯域外更新を公開した。CVE-2026-40372として追跡される権限昇格の脆弱性に対応するもので、CVSSスコアは9.1の緊急評価。認証を持たない攻撃者がネットワーク越しに、認証Cookieを偽造してSYSTEM権限を掌握できるとされる。

問題の出自が異例だ。脆弱性の発端は同月14日のパッチチューズデーで配布されたMicrosoft.AspNetCore.DataProtectionのバージョン10.0.6。このリリース後、一部の利用者から「アプリケーション側で復号が失敗する」との報告が寄せられ、調査の過程で正規のバグと並んで脆弱性が浮上したという流れになる。つまり、定例パッチ自身が新たな穴を開けていた。

修正を担った.NETチームのシニアプログラムマネージャーRahul Bhandariは、バージョン10.0.7のリリースノートでこう書いている。

10.0.6リリース後、一部の利用者からアプリケーションでの復号失敗が報告された。調査の結果、このリグレッション（退行）がセキュリティ脆弱性も露呈させていたことが判明した。

定例パッチが回帰バグを作り、そのバグを調べたら深刻な脆弱性だった。この二段重ねの発覚経緯は、近年の.NETエコシステムでも珍しい。

https://devblogs.microsoft.com/dotnet/dotnet-10-0-7-oob-security-update/

CVE-2026-40372 発覚までの一週間

4月14日

.NET 10.0.6 公開

パッチチューズデーの定例更新としてMicrosoft.AspNetCore.DataProtection 10.0.6を含むNuGetパッケージを配布。

4月16日

復号失敗の報告

利用者がaspnetcore issue #66335で「The payload was invalid」エラーと復号失敗を報告。10.0.5で保護したデータを10.0.6で復号できない現象。

4月16〜20日

調査の過程で脆弱性が判明

リグレッション調査中に、HMAC検証タグが誤ったバイト範囲で計算され破棄される欠陥を特定。単なるバグではなく権限昇格を許す脆弱性と判明。

4月21日

CVE-2026-40372 公開／10.0.7 緊急OOB更新

MSRCアドバイザリー公開（CVSS 9.1 Critical）。.NET 10.0.7を帯域外（OOB）セキュリティ更新として緊急リリース。

※ GitHub上のdotnet/announcements #395、dotnet/aspnetcore #66410、#66335、Microsoft .NET Blog（2026年4月21日付）を基に作成。

HMACが「間違った場所」を守っていた

技術的な核心は暗号処理の手順に潜んでいる。ASP.NET Core データ保護（Data Protection）は、Cookieや偽造防止トークン、TempData、OIDCステートなどを暗号化・署名して往復させるための仕組みだ。10.0.0から10.0.6までのNuGetパッケージには、管理下の認証付き暗号器が、ペイロードの正しいバイト範囲ではなく誤った位置でHMAC検証タグを計算し、その計算結果をそのまま破棄してしまう欠陥が紛れていた。

管理下の認証付き暗号器が、ペイロードの誤ったバイト範囲でHMAC検証タグを計算し、その計算結果を破棄してしまう場合があった。破綻した検証ロジックは、攻撃者がデータ保護の真正性チェックを通過する偽装ペイロードを作り、認証Cookie、偽造防止トークン、TempData、OIDCステートなどの保護済みペイロードを復号することを可能にした。

検証タグがまともに機能していなかったことで、偽造ペイロードが真正性チェックを素通りする構造になっていた。攻撃者はこの隙間をついて、特権ユーザーになりすまし、セッションリフレッシュやAPIキー、パスワードリセットリンクなどの「正当に署名された」トークンをアプリに発行させることができる。

Microsoftのアドバイザリーは、この事象を2010年のMS10-070になぞらえている。当時ASP.NETの旧暗号インフラに存在したパディングオラクル攻撃と、能力的には同等だというのだ。16年越しで似たクラスの脆弱性が、しかも今度は自社の定例パッチを経由して顔を出した。

非Windows環境だけが被弾する不思議

影響範囲の線引きも独特だ。アドバイザリーによれば、Windows環境は影響を受けない。Linux、macOS、その他の非Windows OS上で、net10.0をターゲットに問題のNuGetバイナリを実際にロードしていた場合にのみ発火する。これはWindows版が別の暗号実装（CNGパス）を使うためで、バグは「管理下の認証付き暗号器」のコードパスに限定されている。

影響を受けるのは主に次の条件を満たすアプリケーションだ。Microsoft.AspNetCore.DataProtectionを直接または.StackExchangeRedis、.EntityFrameworkCore、.AzureKeyVault、.AzureStorage、.Redisなどを経由して参照しており、かつ非Windows環境で10.0.6のバイナリが実際にランタイムにロードされていた場合。8.0.xや9.0.xは無関係で、欠陥のあるコードパスは10.0の開発中にのみ混入し、旧系列にはバックポートされていない。

クラウドネイティブな時代にASP.NET CoreをLinuxコンテナで運用するケースは増えている。その層を正面から撃ち抜く影響範囲と言っていい。

環境・構成別 CVE-2026-40372 の影響有無

環境・構成	10.0.6使用	影響
Windows（CNGパス既定）	該当	×
Windows＋managed algorithms明示指定	該当	○
Linux / macOS / 非Windows（net10.0）	NuGetバイナリロード	○
非Windows（net10.0 / 共有フレームワーク優先）	NuGet不使用	×
net462 / netstandard2.0（全OS）	該当	○
.NET 8.0.x / 9.0.x（全OS）	無関係	×

※ ○＝影響あり（要対応）、×＝影響なし。共有フレームワークバージョンがNuGetパッケージ参照バージョン以上の場合、共有フレームワーク側のコードが優先されるため影響を受けない。Microsoft Security Advisory CVE-2026-40372（dotnet/announcements #395）に基づく。

10.0.7に上げただけでは終わらない

修正パッケージ10.0.7へのアップグレードで、偽装ペイロードは今後拒否される。しかし、話はここで終わらない。脆弱な期間中に攻撃者が正当ユーザーとして認証を通過していた場合、そこでアプリが発行した「正規に署名されたトークン」は10.0.7適用後も有効なままだという。セッションリフレッシュトークン、APIキー、パスワードリセットリンク。これらは鍵リング（DataProtectionのキーリング）をローテーションしない限り、元のまま生き残る。

Microsoftは3段階の対応を推奨している。第一にパッケージを10.0.7以上へ更新してデプロイし直す。第二に、脆弱な期間中にインターネット公開エンドポイントを提供していたアプリケーションであれば、鍵リングの全ローテーションを実行する。IKeyManager.RevokeAllKeysを使えば既存の鍵を一括で失効でき、次の保護操作で新しい鍵が自動生成される。ただし全ユーザーの再ログインや偽造防止トークンの再発行を伴うため、運用影響は小さくない。

第三の論点が、鍵ローテーションでも消えない長寿命の遺物だ。データベースに保存されたAPIキーやリフレッシュトークン、発行済みのパスワードリセットリンク、メール確認トークンなど、アプリ層で発行された永続的な権限キャリアは、アプリケーション側で個別に失効させる必要がある。ここを見落とすと、パッチを当てても「すでに盗まれた鍵」が使われ続ける。

半年で2度目のASP.NET Core緊急パッチ

2025年10月には、Kestrelウェブサーバーに関連するHTTPリクエストスマグリング脆弱性CVE-2025-55315が、CVSS 9.9という「ASP.NET Core史上最高」の深刻度で公開されたばかりだった。あの時も権限昇格やSSRF、CSRFバイパスといった連鎖攻撃の可能性が議論の的になった。

半年で2度のASP.NET Core緊急パッチ

項目	CVE-2025-55315	CVE-2026-40372
公開日	2025年10月14日	2026年4月21日（OOB）
CVSS	9.9 Critical	9.1 Critical
種別	セキュリティ機能バイパス	権限昇格（EoP）
原因	HTTPリクエストスマグリング	HMAC検証タグの計算位置誤り
対象	Kestrelウェブサーバー	Microsoft.AspNetCore.DataProtection
影響範囲	ASP.NET Core 8/9/10、2.3（Kestrel）	10.0.0〜10.0.6（非Windows中心）
発覚経緯	研究者からの報告（$10K懸賞）	定例パッチのリグレッション調査中

※ Microsoft Security Response Center公開のアドバイザリー、および.NETチーム公式発表に基づく。CVE-2025-55315は「ASP.NET Core史上最高」のCVSSスコアとして公開時に報じられた。

そして半年も経たずに、今度は定例パッチ自身が引き金を引いた脆弱性が出てくる。Microsoftは10.0.7で復号リグレッションとセキュリティ脆弱性の両方を同時に潰した。パッチチューズデーから緊急OOBまで一週間というサイクルは、近年のサービシングプロセスでも緊張感のある数字だ。

攻撃者が脆弱な期間中に偽装ペイロードで特権ユーザーとして認証していた場合、アプリケーションに正規に署名されたトークンを自身に対して発行させた可能性がある。これらのトークンは、データ保護のキーリングをローテーションしない限り10.0.7にアップグレードした後も有効なまま残る。

「パッチ適用」というサイクル自体が、信頼の再構築ではなく新たな攻撃面の提供になりかねない。この構造は、運用者がパッチ管理の自動化に傾けば傾くほど深刻化していく問題だ。.NET 10.0.6が配られてから10.0.7が出るまでの一週間、非Windowsで本番を回していた組織は、知らないうちにリスクウィンドウの中にいた。

セキュリティアップデートを疑わずに当てる文化と、当てたパッチを再度検証する文化。前者だけで走ってきたチームほど、今回の件は足元を見直す機会になるはずだ。

参照元