CVE-2026-62721は、Windows User-Mode Power Service(UMPS)に存在するローカル権限昇格の脆弱性です。Windows 11では、2026年8月のセキュリティ更新プログラムまたは、それ以降の累積更新プログラムを導入し、OSビルドが修正済み基準以上になっていることを確認すれば対策できます。
具体的には、Windows 11 23H2はKB5120240、24H2と25H2はKB5121003、26H1はKB5121000が修正を含む更新プログラムです。KB番号だけでなく、23H2は22631.7517、24H2は26100.9168、25H2は26200.9168、26H1は28000.2704以上であることを確認してください。(Microsoft セキュリティレスポンスセンター)
CVE-2026-62721とは
CVE-2026-62721は、Windowsの電源管理に関わるUser-Mode Power Service、略称UMPSのアクセス制御に問題がある脆弱性です。
公開情報では、アクセス制御の粒度が不十分であることを示す「CWE-1220」に分類されています。低い権限を持つローカルの攻撃者が脆弱性を悪用すると、本来許可されていない高い権限へ昇格できる可能性があります。(CVE)
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-62721 |
| 対象コンポーネント | Windows User-Mode Power Service(UMPS) |
| 脆弱性の種類 | 権限昇格 |
| 原因 | アクセス制御の粒度不足 |
| 攻撃経路 | ローカル |
| 攻撃の複雑さ | 低い |
| 攻撃前に必要な権限 | 低い権限 |
| ユーザー操作 | 不要 |
| CVSS v3.1 | 7.8/High |
| CVSSベクター | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
「ローカル攻撃」でも優先度を下げすぎない
この脆弱性は、インターネットから対象PCへ直接アクセスするだけで悪用できる種類ではありません。攻撃者は、あらかじめ標準ユーザーなどの権限で対象端末にアクセスし、ローカルで処理を実行できる状態にしておく必要があります。
しかし、次のような攻撃の後段で使われる可能性があります。
- フィッシングメールからマルウェアを実行された
- ブラウザーや業務アプリの別の脆弱性を悪用された
- 標準ユーザーの認証情報を盗まれた
- 共用PCへ不正な利用者がログオンした
- ソフトウェア配布経路へ不正なプログラムを混入された
標準ユーザー権限だけでは実行できる操作が限られていても、権限昇格に成功すると、端末内の情報取得、設定変更、セキュリティ機能への干渉などにつながる可能性があります。
そのため、「ネットワーク経由ではないから後回し」と判断するのではなく、すでに端末内へ侵入された場合の被害拡大を防ぐ更新として扱う必要があります。
CVE-2026-62721を修正するKBと対応ビルド
Windows 11でCVE-2026-62721を修正する2026年8月の更新プログラムと、適用後のOSビルドは次のとおりです。
| Windows 11のバージョン | 修正KB | 修正済みとなるOSビルド |
|---|---|---|
| Windows 11 23H2 | KB5120240 | 22631.7517以上 (マイクロソフトサポート) |
| Windows 11 24H2 | KB5121003 | 26100.9168以上 (マイクロソフトサポート) |
| Windows 11 25H2 | KB5121003 | 26200.9168以上 (マイクロソフトサポート) |
| Windows 11 26H1 | KB5121000 | 28000.2704以上 (マイクロソフトサポート) |
24H2と25H2には同じKB5121003が配信されますが、適用後のビルド番号は異なります。確認するときは、KB番号だけでなくWindowsのバージョンとビルド番号を組み合わせて判断してください。
KB番号が見つからなくてもビルドが新しければ修正済み
Windows 11の月例更新プログラムは累積形式です。後から公開された累積更新プログラムには、それ以前のセキュリティ修正も原則として含まれます。(Microsoft Learn)
そのため、更新履歴にKB5121003などが表示されていなくても、同じWindowsバージョンでOSビルドが基準以上であれば、CVE-2026-62721の修正を含む後続更新が導入されていると判断できます。
例えばWindows 11 24H2の場合は、次のように判定します。
| 確認結果 | 判定 |
|---|---|
| OSビルドが26100.9168未満 | 修正済み基準に未到達 |
| OSビルドが26100.9168 | 2026年8月の修正済み基準を満たす |
| OSビルドが26100.9168より新しい | 後続の累積更新に修正が含まれている |
| KB5121003が履歴にないがビルドは基準以上 | 基本的には対策済み |
| KB5121003が履歴にあるが再起動待ち | 再起動後にビルドを再確認 |
脆弱性管理では、「KBがインストール済みか」だけを検査するよりも、Windowsのバージョンごとに最低ビルドを設定して判定する方法が確実です。
WindowsのバージョンとOSビルドを確認する方法
winverで確認する
個人PCや少数の端末であれば、winverを使う方法が簡単です。
WindowsキーとRキーを同時に押します。- 「ファイル名を指定して実行」に
winverと入力します。 - 「OK」を選択します。
- 表示されたバージョンとOSビルドを確認します。
- 修正済みビルドの表と照合します。
確認画面に「バージョン 24H2」「OS ビルド 26100.9168」のように表示されていれば、CVE-2026-62721の修正済み基準を満たしています。
PowerShellで確認する
PowerShellでは、レジストリからバージョンとビルド番号をまとめて取得できます。
$os = Get-ItemProperty `
'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
[pscustomobject]@{
ProductName = $os.ProductName
DisplayVersion = $os.DisplayVersion
OSBuild = "$($os.CurrentBuildNumber).$($os.UBR)"
}
複数のWindows 11バージョンを自動判定したい場合は、次のスクリプトを使用できます。
$os = Get-ItemProperty `
'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$displayVersion = $os.DisplayVersion
$installedBuild = [version](
"{0}.{1}" -f $os.CurrentBuildNumber, $os.UBR
)
$fixedBuilds = @{
'23H2' = [version]'22631.7517'
'24H2' = [version]'26100.9168'
'25H2' = [version]'26200.9168'
'26H1' = [version]'28000.2704'
}
if ($fixedBuilds.ContainsKey($displayVersion)) {
$requiredBuild = $fixedBuilds[$displayVersion]
if ($installedBuild -ge $requiredBuild) {
$status = '修正済み基準を満たしています'
}
else {
$status = '修正済み基準未満です。更新が必要です'
}
$requiredBuildText = $requiredBuild.ToString()
}
else {
$status = 'このスクリプトの判定対象外です'
$requiredBuildText = '-'
}
[pscustomobject]@{
ProductName = $os.ProductName
DisplayVersion = $displayVersion
InstalledBuild = $installedBuild.ToString()
RequiredBuild = $requiredBuildText
CVE202662721State = $status
}
判定結果が「修正済み基準未満です」となった端末は、Windows Updateや組織の更新管理システムから最新の累積更新プログラムを導入します。
CVE-2026-62721の更新プログラムを適用する手順
個人PCや少数端末の場合
- 「設定」を開きます。
- 「Windows Update」を選択します。
- 「更新プログラムのチェック」を実行します。
- 利用可能な累積更新プログラムをインストールします。
- 再起動を求められた場合は再起動します。
winverを実行し、OSビルドが修正済み基準以上になったことを確認します。
KB5120240、KB5121003、KB5121000は、Windows Update、Windows Update for Business、Microsoft Update Catalog、WSUSなどの経路で提供されています。(マイクロソフトサポート)
更新画面に2026年8月のKBが表示されず、より新しい累積更新プログラムが表示される場合は、古いKBを探して個別に入れるのではなく、原則として新しい累積更新プログラムを適用します。
IntuneやWSUSで管理している場合
組織では、次の順序で展開すると適用漏れを減らせます。
| 段階 | 実施内容 |
|---|---|
| 資産確認 | DisplayVersion、CurrentBuildNumber、UBRを収集する |
| 対象判定 | バージョンごとの最低ビルド未満を抽出する |
| 先行展開 | IT部門や検証用端末へ適用する |
| 動作確認 | 業務アプリ、VPN、認証、周辺機器を確認する |
| 全体展開 | Windows Update for Business、Intune、WSUSなどで配信する |
| 完了確認 | KBの有無ではなく、再起動後のOSビルドを確認する |
| 例外処理 | オフライン端末や更新失敗端末を個別に追跡する |
特にノートPCは、長期間社内ネットワークへ接続されず、更新のダウンロードや再起動が完了していないことがあります。「配信済み」ではなく「修正済みビルド到達済み」を完了条件にしてください。
Microsoft Update Catalogから手動導入する場合
インターネットへ直接接続できない端末や、Windows Updateで配信されない端末では、Microsoft Update Catalogから対象KBを取得できます。
手動導入時は、次の点に注意してください。
- Windowsのバージョンを間違えない
- x64とARM64を間違えない
- Catalogに複数のMSUが表示された場合は、すべて確認する
- 前提パッケージを飛ばさない
- インストール後に再起動し、OSビルドを確認する
KB5121003は、環境によって複数のMSUファイルを指定された順序で導入する必要があります。Microsoftは、必要なファイルを同じフォルダーへ配置してDISMに前提パッケージを検出させる方法と、KBページに記載された順序で個別導入する方法を案内しています。対象KBのMSUファイルだけを単独で実行すると、前提条件不足で適用できない可能性があります。(マイクロソフトサポート)
更新できない場合の確認ポイント
更新プログラムが表示されない
Windows Updateに対象の更新が表示されない場合は、次を確認します。
- 更新の一時停止が有効になっていないか確認します。
- 組織の更新ポリシーで延期されていないか確認します。
- Windowsのバージョンとエディションがサポート対象か確認します。
- すでに後続の累積更新プログラムが導入されていないか確認します。
- 再起動待ちの更新が残っていないか確認します。
- ディスクの空き容量を確保します。
すでにOSビルドが基準以上であれば、2026年8月のKBが個別に表示されなくても、追加で古いKBを導入する必要はありません。
インストールが失敗する
更新コンポーネントやWindowsのシステムファイルに問題が疑われる場合は、管理者としてターミナルまたはコマンドプロンプトを開き、次の順序で実行します。
DISM /Online /Cleanup-Image /RestoreHealth
処理が完了したら、続けて次を実行します。
sfc /scannow
完了後にWindowsを再起動し、Windows Updateを再実行します。
Microsoft Update Catalogから導入したパッケージで「この更新プログラムはお使いのコンピューターには適用できません」と表示された場合は、バージョン、CPUアーキテクチャ、前提MSU、すでに導入されている後続ビルドを確認してください。
KBは表示されるがビルドが変わらない
更新履歴に「正しくインストールされました」と表示されていても、再起動が完了するまで新しいOSビルドへ切り替わらないことがあります。
次の状態を確認してください。
- Windows Updateに「再起動が必要です」と表示されていないか
- シャットダウンではなく更新を伴う再起動が完了しているか
- 更新がロールバックされていないか
- Windows Updateの履歴に失敗記録がないか
脆弱性対策の完了判定は、更新履歴の表示だけでなく、再起動後のOSビルドで行います。
Windows 11 23H2はエディションによって対応が異なる
Windows 11 23H2 HomeおよびProは、2025年11月11日に更新提供が終了しています。これらのエディションを使用している場合は、KB5120240の手動導入だけで運用を続けるのではなく、サポートされているWindows 11へアップグレードする必要があります。
23H2 EnterpriseおよびEducationは2026年11月10日までセキュリティ更新を受け取れますが、終了日が近いため、CVE-2026-62721への対応と並行して25H2などへの移行計画を進めるべきです。(Microsoft Learn)
また、Windows 11 24H2 HomeおよびProも2026年10月13日に更新提供が終了する予定です。24H2ではKB5121003を適用して今回の脆弱性を修正するとともに、25H2などサポート期間が残っているバージョンへの移行を検討してください。(マイクロソフトサポート)
KB5121003適用後にゲームが停止する場合
Microsoftは、KB5121003の適用後、一部のゲームが応答しなくなる、予告なく終了する、端末が再起動するといった報告を公開しています。
調査では、RGBライティング対応機器などが導入するinpoutx64に類似した名前のドライバーやソフトウェアコンポーネントとの関連が確認されています。Microsoftは、該当ドライバーの読み込みをブロックする対策を提供しています。
一般利用者やIT部門に管理されていない企業端末には対策が自動適用されますが、企業管理端末には自動で反映されない場合があります。該当する組織は、Windowsリリース正常性情報に掲載された企業向けの回避策を確認してください。(マイクロソフトサポート)
不具合が発生した場合でも、最初からKB5121003をアンインストールしてセキュリティ修正まで取り除くのは避けます。先にMicrosoftが案内する対策、周辺機器用ユーティリティやドライバーの更新、対象ソフトウェアの停止を検討します。
CVE-2026-62721対策として不十分な対応
UMPSを無効化する
Microsoftが公式な回避策として案内していないサービス停止は、電源管理や周辺機器の動作へ影響する可能性があります。サービスを停止しても、更新プログラムの導入に代わる恒久対策にはなりません。
標準ユーザー運用だけで済ませる
この脆弱性は、低い権限を持つ攻撃者による権限昇格が想定されています。利用者を標準ユーザーにしていることは重要な防御策ですが、それだけではCVE-2026-62721への対策になりません。
ファイアウォールで外部通信を遮断する
攻撃経路はローカルであるため、インターネットからの受信通信を遮断するだけでは修正できません。ファイアウォールは侵入経路の削減には役立ちますが、脆弱なアクセス制御そのものは残ります。
セキュリティソフトの検知だけに依存する
セキュリティソフトは既知の攻撃手法や不審な動作を検知できる場合がありますが、脆弱性の修正にはなりません。攻撃コードの変更や別の侵入経路を考慮し、Windowsの累積更新プログラムを導入してください。
対応時に優先したい端末
CVE-2026-62721は、次のような端末から優先的に更新すると効果的です。
- 多数の利用者がログオンする共用PC
- 外部委託先や一時利用者が操作する端末
- 開発ツールやスクリプト実行環境を備えたPC
- インターネットやメールを日常的に利用する端末
- ローカル管理者資格情報を扱う運用端末
- 長期間社内ネットワークへ接続されていないノートPC
- セキュリティ更新の再起動を長期間延期している端末
インターネットへ直接公開しているかどうかだけで優先順位を決めないことが重要です。ローカルでコードを実行された後の被害拡大を防ぐという観点から、利用者との接点が多い端末や、重要な認証情報を扱う端末を優先します。
CVE-2026-62721への対応まとめ
CVE-2026-62721への対応では、次の順序で確認してください。
- Windows 11のバージョンとOSビルドを取得します。
- 23H2は22631.7517、24H2は26100.9168、25H2は26200.9168、26H1は28000.2704以上か確認します。
- 基準未満ならWindows Update、Intune、WSUSなどから最新の累積更新プログラムを導入します。
- 再起動後にOSビルドを再確認します。
- 基準未満の端末や更新失敗端末を例外として追跡します。
- 23H2 Home・Proなどサポート終了済みの環境は、サポート中のWindows 11へ移行します。
KB5120240、KB5121003、KB5121000はCVE-2026-62721の修正を含みますが、後続の累積更新プログラムでも対策できます。更新履歴に特定のKBがあるかだけで判断せず、同じWindowsバージョンで修正済みビルド以上に到達しているかを最終的な完了条件にしてください。

コメント