CVE-2026-50661は、攻撃者が端末を物理的に操作できる場合に、Windows BitLockerの保護機構を回避できる脆弱性です。インターネット経由だけで悪用できる脆弱性ではなく、BitLockerの暗号アルゴリズムそのものが解読されたという意味でもありません。
直接的な対処は、対象OSに2026年7月のセキュリティ更新、またはそれ以降の累積更新を適用し、OSビルドを修正済みの値以上にすることです。ただし、更新によってCVE-2026-50661を修正しても、端末の盗難対策、BitLockerの有効化、回復キーの管理まで自動的に改善されるわけではありません。更新状況とBitLockerの運用状況を別々に確認する必要があります。(Microsoft Security Response Center)
| 読者が知りたい点 | 結論 |
|---|---|
| ネットワーク経由でBitLockerを突破されるのか | このCVEは物理アクセスが前提 |
| 暗号化アルゴリズムが破られたのか | 公開情報は暗号解読ではなく、保護機構の回避を示している |
| 更新だけでCVEを修正できるか | 修正済みビルド以上への更新が直接的な対処 |
| 更新すれば端末の盗難対策も十分か | 不十分。物理管理、BitLocker状態、回復キー管理も必要 |
| 修正KBと異なるKBが入っている場合は未修正か | 後続の累積更新でビルドが基準以上なら修正を含む |
CVE-2026-50661とは何か
CVE-2026-50661は、Windows BitLockerにおける「保護機構の不備」に分類されるセキュリティ機能回避の脆弱性です。CWEはCWE-693、CVSS v3.1の基本値は6.1で、深刻度はMediumと評価されています。
CVSSベクトルは次のとおりです。
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
主な意味は次のとおりです。
| 指標 | 評価 | 実務上の意味 |
|---|---|---|
| Attack Vector | Physical | 攻撃者が対象端末を物理的に操作する必要がある |
| Attack Complexity | Low | 前提を満たした後の攻撃難度は低いと評価されている |
| Privileges Required | None | Windowsアカウントなどの事前権限を必要としない |
| User Interaction | None | 利用者にファイルを開かせるなどの操作を要求しない |
| Confidentiality | High | 情報の機密性に大きな影響を与える可能性がある |
| Integrity | High | データやシステムの完全性に大きな影響を与える可能性がある |
| Availability | None | 可用性への直接的な影響は評価されていない |
CVSSが6.1にとどまっている大きな理由は、物理アクセスが必要なためです。一方で、いったん端末を物理的に確保されると、事前権限やユーザー操作を必要とせず、機密性と完全性への影響が高いと評価されています。ノートPCの持ち出しが多い組織や、不特定多数が端末に触れられる環境では、数値だけを見て対応を後回しにすべきではありません。(NVD)
CVE-2026-50661はBitLockerをどのように回避するのか
MicrosoftとNVDが公開している説明では、攻撃者が物理攻撃によってBitLockerのセキュリティ機能を回避できることが示されています。
ただし、公開情報から確実に確認できるのは、次の範囲です。
| 公開情報で確認できること | 公開情報だけでは断定できないこと |
|---|---|
| BitLockerの保護機構に不備がある | 具体的にどの画面や入力を悪用するのか |
| 物理アクセスが必要 | 任意のUSBメモリだけで再現できるか |
| 攻撃難度はLowと評価されている | すべてのBitLocker構成で同じ手順が使えるか |
| 事前権限とユーザー操作は不要 | TPM、回復環境、ブートローダーのどこが攻撃経路になるか |
| 機密性と完全性への影響が高い | 再現可能な攻撃コードや完全な手順 |
したがって、「USBメモリから起動すればBitLockerを解除できる」「回復環境を開くだけで暗号化ドライブを読める」といった具体的な攻撃手順を、根拠なく断定するのは不正確です。
現時点での正確な説明は、端末を物理的に操作できる攻撃者が、BitLockerの保護機構の不備を利用し、本来遮断されるべきアクセスを可能にする脆弱性というものです。これはAESなどの暗号方式を総当たりで解読する攻撃ではなく、BitLockerを構成する保護処理を回避する問題として扱う必要があります。(Microsoft Security Response Center)
「公開済み」と「悪用確認済み」は同じではない
CVE情報が公開されていることと、実際の攻撃が広く観測されていることは別です。
「公開済み」は、脆弱性の識別子、影響、対象製品、修正情報などが公表されている状態を示します。それだけを根拠に、「すでにランサムウェア攻撃で大規模に悪用されている」と判断することはできません。
一方で、攻撃手法が広く観測されるまで対応を待つのも適切ではありません。物理アクセスを許す可能性がある端末では、紛失や盗難が発生した時点で攻撃条件が成立するため、修正済みビルドへの更新を先に進めるべきです。
対象となるWindowsと修正KB・固定ビルド
CVE-2026-50661は、Windows 10、Windows 11、Windows Serverの複数バージョンに影響します。
ここで重要なのは、KB番号だけではなく、OSのフルビルド番号で修正状態を確認することです。後続の累積更新がインストールされると、最初に修正を提供したKBとは別のKB番号になります。
Windows 10とWindows 11
| OS | 影響を受けるビルド | 2026年7月14日の初回修正KB | 修正済みビルド |
|---|---|---|---|
| Windows 10 Version 1607 | 14393.9339未満 | KB5099535 | 14393.9339 |
| Windows 10 Version 1809 | 17763.9020未満 | KB5099538 | 17763.9020 |
| Windows 10 Version 21H2 | 19044.7548未満 | KB5099539 | 19044.7548 |
| Windows 10 Version 22H2 | 19045.7548未満 | KB5099539 | 19045.7548 |
| Windows 11 Version 24H2 | 26100.8875未満 | KB5101650 | 26100.8875 |
| Windows 11 Version 25H2 | 26200.8875未満 | KB5101650 | 26200.8875 |
| Windows 11 Version 26H1 | 28000.2525未満 | KB5101649 | 28000.2525 |
Windows 11については、公開された影響範囲に24H2、25H2、26H1が記載されています。Windows 11という製品名だけで判断せず、バージョンとビルドを確認してください。(NVD)
Windows Server
| OS | 影響を受けるビルド | 2026年7月14日の初回修正KB | 修正済みビルド |
|---|---|---|---|
| Windows Server 2016 | 14393.9339未満 | KB5099535 | 14393.9339 |
| Windows Server 2019 | 17763.9020未満 | KB5099538 | 17763.9020 |
| Windows Server 2022 | 20348.5386未満 | KB5099540 | 20348.5386 |
| Windows Server 2025 | 26100.33158未満 | KB5099536 | 26100.33158 |
Server Coreインストールも、対応するWindows Serverバージョンの基準で確認します。(NVD)
Windows 11 24H2とWindows Server 2025を取り違えない
Windows 11 Version 24H2とWindows Server 2025は、どちらもビルド系列が「26100」で始まります。しかし、CVE-2026-50661の修正済みリビジョンは異なります。
- Windows 11 Version 24H2:26100.8875以上
- Windows Server 2025:26100.33158以上
「26100だから8875以上ならよい」と一律に判断すると、Windows Server 2025を誤判定します。必ず製品名とバージョンを確認してから、対応する行の固定ビルドと比較してください。
後続更新ではKB番号が変わる
2026年7月14日の修正KBは、CVE-2026-50661を最初に修正した累積更新です。その後に新しい累積更新や帯域外更新が配信された場合は、別のKB番号が表示されます。
たとえば、Windows 11 Version 24H2および25H2には、2026年7月18日にKB5121767が公開され、OSビルドは26100.8894および26200.8894となっています。これらは固定ビルドの8875を上回っています。したがって、KB5101650が履歴に見当たらなくても、より新しい累積更新が適用されていれば、このCVEについて未修正とは限りません。(マイクロソフトサポート)
確認時は次の順番で判断すると誤りを防げます。
- OSの製品名とバージョンを確認する
- フルビルド番号を確認する
- 対応する固定ビルド以上か比較する
- 補助情報として更新履歴のKB番号を確認する
自分のPCやサーバーが修正済みか確認する手順
Windowsの画面から確認する
最も簡単なのは、winverを実行する方法です。
WindowsキーとRキーを押す- 「ファイル名を指定して実行」に
winverと入力する - 表示されたバージョンとOSビルドを確認する
- 対応表の固定ビルド以上か比較する
たとえば、Windows 10 Version 22H2で次のように表示された場合は修正済みです。
バージョン 22H2
OS ビルド 19045.7548
次の場合は未修正です。
バージョン 22H2
OS ビルド 19045.7400
同じ「22H2」であっても、末尾のリビジョンが7548未満ならCVE-2026-50661の固定ビルドに達していません。
PowerShellでフルビルドを確認する
複数端末を管理している場合や、リモート管理で確認する場合はPowerShellが便利です。
$os = Get-CimInstance Win32_OperatingSystem
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
[pscustomobject]@{
OS = $os.Caption
DisplayVersion = $cv.DisplayVersion
Build = "$($cv.CurrentBuildNumber).$($cv.UBR)"
}
出力例は次のとおりです。
OS : Microsoft Windows 11 Pro
DisplayVersion : 24H2
Build : 26100.8875
CurrentBuildNumberだけを取得すると「26100」までしか分からず、修正済みか判断できません。必ずUBRを含めた「26100.8875」の形式で確認してください。
更新履歴でKBを確認する
Windows 11では、次の画面から確認できます。
設定
→ Windows Update
→ 更新の履歴
→ 品質更新プログラム
Windows 10では、次の画面を開きます。
設定
→ 更新とセキュリティ
→ Windows Update
→ 更新の履歴を表示する
PowerShellでは、最近の修正プログラムを次のコマンドで確認できます。
Get-HotFix |
Sort-Object InstalledOn -Descending |
Select-Object -First 20 HotFixID, InstalledOn, Description
ただし、Get-HotFixの結果だけで最終判断しないでください。更新の種類や管理方式によっては、期待したKBが一覧に表示されないことがあります。CVE-2026-50661の修正確認では、フルビルド番号を優先するのが確実です。
更新が適用できない場合に確認すること
Windows Updateに修正が表示されない場合は、次の点を確認します。
| 確認項目 | 主な問題 |
|---|---|
| Windowsのバージョン | 別バージョン用のKBを探している |
| サポート対象か | サポート終了OSで通常の更新を受け取れない |
| ESUなどの契約 | Windows 10の一部環境で拡張セキュリティ更新が必要 |
| WSUSや更新ポリシー | 管理者が更新を未承認または延期している |
| 再起動状態 | 更新のインストールが再起動待ちになっている |
| ディスク空き容量 | 累積更新を展開できる空き容量がない |
| 保留中の更新 | 以前の更新失敗が後続更新を妨げている |
Windows 10の一部バージョンやエディションでは、2026年7月時点の更新を受け取るために、ESUなど適切なサポート条件が必要になる場合があります。更新が提示されないときは、単に「脆弱性の対象外」と判断せず、ライフサイクルと更新契約を確認してください。(マイクロソフトサポート)
BitLockerが実際に保護状態か確認する
OSを更新しても、BitLockerが無効または一時停止されていれば、端末の保存データは期待した状態で保護されません。
管理者権限のコマンドプロンプトで、次を実行します。
manage-bde -status
PowerShellを利用する場合は次のコマンドでも確認できます。
Get-BitLockerVolume |
Select-Object MountPoint, VolumeStatus, ProtectionStatus, EncryptionPercentage
システムドライブでは、少なくとも次の状態を確認します。
| 項目 | 望ましい状態 |
|---|---|
| Volume Status | FullyEncrypted |
| Encryption Percentage | 100 |
| Protection Status | On |
| Key Protector | TPM、回復パスワード、必要に応じてTPM+PIN |
「暗号化済み」と「保護が有効」は同じではありません。ボリュームが100%暗号化されていても、BitLockerの保護が一時停止されている場合は、Protection StatusがOffになります。
つまり、次の2つは別々に確認する必要があります。
winverやOSビルド:CVE-2026-50661が修正されているかmanage-bde -status:BitLockerが現在有効に保護しているか
BitLockerは、紛失、盗難、廃棄などによるデータ漏えいを抑えるため、ボリューム全体を暗号化する機能です。TPM、セキュアブート、測定されたブートなどの技術と組み合わせることで、起動環境の信頼性を高められます。(Microsoft Learn)
更新だけで対処できるのか
CVE-2026-50661そのものに対する直接的な対処は、固定ビルド以上への更新です。その意味では、対象OSに適切なセキュリティ更新を適用することが中心的な対応になります。
しかし、端末の物理セキュリティ全体を考えると、更新だけでは不十分です。
| 状態 | CVEの修正 | データ保護の評価 |
|---|---|---|
| 固定ビルド未満、BitLocker有効 | 未修正 | 物理アクセス時にCVEの影響を受ける可能性がある |
| 固定ビルド以上、BitLocker有効 | 修正済み | このCVEには対処済み。物理管理は引き続き必要 |
| 固定ビルド以上、BitLocker無効 | 修正済み | このCVEは修正済みだが、保存データはBitLockerで保護されない |
| 固定ビルド以上、保護一時停止 | 修正済み | 暗号化済みでも保護が有効とは限らない |
| 固定ビルド以上、回復キー漏えい | 修正済み | 正規の回復キーを使われる別のリスクが残る |
| 未修正端末を紛失済み | 未確認 | 更新だけでは過去の物理アクセスや侵害を否定できない |
更新によって修正できるのは、あくまでCVE-2026-50661を発生させた実装上の不備です。盗難防止、回復キーの漏えい、利用者が端末をロックせずに離席する問題などは、別の対策が必要です。
物理アクセスを許す端末で継続すべき対策
持ち出し端末と共有端末を優先して更新する
優先度が高いのは、次のような端末です。
- 社外へ持ち出すノートPC
- 出張やテレワークで利用する端末
- 受付、店舗、工場、学校などの共有端末
- 不特定多数が出入りする場所に設置したPC
- 施錠されていない場所に置かれた小型サーバー
- 廃棄、修理、リース返却を予定している端末
データセンター内のサーバーでも対象OSであれば更新は必要です。ただし、施錠されたサーバールーム内の機器より、紛失や盗難が起きやすいノートPCを先に修正する方が、物理攻撃の成立可能性を早く下げられます。
TPMとセキュアブートの状態を確認する
BitLockerだけでなく、TPMとセキュアブートの状態も確認します。
TPMは、次のコマンドで確認できます。
Get-Tpm
セキュアブートは、UEFI環境のPowerShellで次のコマンドから確認できます。
Confirm-SecureBootUEFI
ただし、TPMやセキュアブートを有効にするだけで、CVE-2026-50661の更新が不要になるわけではありません。これらは更新を置き換える回避策ではなく、別レイヤーの防御です。
高リスク端末ではTPM+PINを検討する
TPMのみのBitLocker構成では、通常の起動時に利用者がBitLocker用PINを入力する必要がありません。持ち出し端末など、物理攻撃のリスクが高い環境では、起動前認証としてTPM+PINを要求する構成を検討できます。
MicrosoftのBitLocker計画ガイドでも、TPMと起動時PINの組み合わせは、物理攻撃者がWindowsのサインイン画面へ到達する前に追加の認証を要求する防御として説明されています。(Microsoft Learn)
ただし、TPM+PINには次の運用負荷があります。
| 項目 | 注意点 |
|---|---|
| 利用者教育 | Windowsログインとは別のPINであることを説明する |
| PIN忘れ | ヘルプデスクでの回復手順を整備する |
| 無人再起動 | 更新後の自動再起動や遠隔運用に影響する |
| 共有端末 | PINの共有や定期変更ルールが必要になる |
| サーバー | 無人起動要件との整合を確認する |
すべての端末に一律導入するのではなく、持ち出し頻度、保存データ、再起動運用を基準に判断するのが現実的です。
外部メディアからの起動を制限する
UEFI設定で、不要な外部メディアやネットワークからの起動を制限します。必要に応じてUEFI管理者パスワードも設定し、利用者や第三者がブート順序を変更できないようにします。
ただし、外部起動の無効化がCVE-2026-50661を完全に防ぐとMicrosoftが示しているわけではありません。あくまで物理攻撃の選択肢を減らすための追加対策として扱い、修正更新は必ず適用してください。
搬送・保管時は電源状態にも注意する
端末を鞄に入れて持ち運ぶ場合や、長時間無人になる場所へ保管する場合は、画面ロックだけに依存しない運用を検討します。
特に機密性の高いデータを扱う端末では、スリープ状態のまま持ち運ぶのではなく、シャットダウンまたは組織で定めた安全な休止状態へ移行させる方が適しています。
BitLocker回復キーを安全に管理する
BitLocker回復キーは、通常48桁の数値です。利用者がPINを忘れた場合、TPMの検証に失敗した場合、ハードウェアや起動構成が変更された場合などに必要になります。
Microsoftは、失われた回復キーをサポート窓口で再作成したり、代わりに取得したりすることはできないと案内しています。更新前に回復キーを確認しておくことは重要ですが、確認のためにキーをメール、チャット、一般的な問い合わせ票へ貼り付けるのは避けてください。(マイクロソフトサポート)
組織では、次の条件を満たす管理が必要です。
| 管理項目 | 推奨される対応 |
|---|---|
| 保管場所 | Microsoft Entra ID、Active Directoryなどの管理された場所へ集約 |
| 閲覧権限 | ヘルプデスク全員ではなく、必要な担当者に限定 |
| 本人確認 | 利用者名だけで回復キーを渡さない |
| 監査 | 誰が、いつ、どの端末のキーを取得したか記録 |
| 転記 | メール、チャット、共有表への平文転記を禁止 |
| 端末廃棄 | デバイス情報と回復キーの削除手順を連動 |
| 漏えい時 | 回復キーの再生成や保護機能の再構成を検討 |
Microsoft Entra IDやIntuneで管理している端末では、デバイスに関連付けられた回復キーを管理画面から確認できます。閲覧権限と取得履歴を含め、キーそのものだけでなく、取り扱い手順も管理してください。(Microsoft Learn)
組織での対応優先順位
全端末を一度に更新できない場合は、物理アクセスの可能性と保存データの重要度で優先順位を決めます。
| 優先度 | 端末例 | 対応 |
|---|---|---|
| 最優先 | 持ち出しPC、紛失中の端末、共有スペースのPC | 更新、再起動、ビルド確認を直ちに実施 |
| 高 | 管理職PC、個人情報・認証情報を扱う端末 | 早期更新と回復キー確認 |
| 中 | 施錠された事務室内のデスクトップ | 通常の緊急パッチ枠で更新 |
| 中 | サーバールーム内のWindows Server | 保守時間を確保し、固定ビルド以上へ更新 |
| 別途緊急 | BitLocker無効・一時停止の端末 | 更新に加えて暗号化ポリシーを是正 |
| インシデント対応 | 未修正状態で紛失・盗難された端末 | 更新作業ではなく、侵害を想定した対応へ移行 |
実務では、次の順序で進めると確認漏れを防げます。
- Windows 10、Windows 11、Windows Serverの端末一覧を抽出する
- OSバージョンとフルビルドを収集する
- 固定ビルド未満の端末を抽出する
- 持ち出し端末と物理的に触れやすい端末を優先する
- 2026年7月の更新または後続累積更新を配信する
- 再起動後にフルビルドを再取得する
- BitLockerの
Protection Statusを確認する - 回復キーが管理基盤に保管されているか確認する
- 更新失敗端末と長期オフライン端末を例外一覧に残す
- 紛失済み端末はセキュリティインシデントとして別管理する
管理台帳に残すべき項目
更新作業の完了判定は、「更新を配信した」ではなく「端末が固定ビルド以上になった」で行います。
最低限、次の項目を記録します。
| 項目 | 例 |
|---|---|
| 端末名 | PC-00123 |
| 利用者・設置場所 | 営業部・持ち出し |
| OS | Windows 11 Pro |
| バージョン | 24H2 |
| 更新前ビルド | 26100.8200 |
| 更新後ビルド | 26100.8894 |
| BitLocker状態 | Protection On |
| 回復キー保管 | Microsoft Entra ID |
| 確認日 | 2026年7月19日 |
| 例外理由 | 再起動待ち、長期出張など |
KB番号だけを台帳に残すと、後続更新へ置き換わった際に状況を追いにくくなります。OS、バージョン、フルビルド、BitLocker状態をセットで記録するのがポイントです。
よくある誤解と判断方法
CVSS 6.1なので急がなくてもよい
CVSSでは物理アクセスが必要なため、ネットワーク経由の脆弱性よりスコアが低くなっています。しかし、機密性と完全性への影響はHighです。
持ち出しPCでは、盗難そのものが攻撃条件の成立につながります。端末の利用形態を考慮せず、Mediumというラベルだけで優先度を下げるのは適切ではありません。
BitLockerが有効なら更新しなくてもよい
誤りです。CVE-2026-50661はBitLockerの保護機構を回避する脆弱性であるため、BitLockerが有効な端末こそ修正対象です。
BitLockerの有効化は更新の代替策ではありません。
KB5099539が見つからないので未修正である
必ずしも未修正ではありません。後続の累積更新が適用されていれば、別のKB番号になります。
たとえばWindows 10 Version 22H2では、OSビルドが19045.7548以上かどうかを先に確認します。KB番号は補助的な確認材料です。
固定ビルド以上ならBitLockerの確認は不要である
固定ビルド以上で分かるのは、CVE-2026-50661の修正が含まれていることです。BitLockerが無効、一時停止、暗号化途中である可能性は残ります。
修正ビルドとBitLocker状態は別の管理項目です。
更新後にドライブを復号して再暗号化する必要がある
公開されている修正情報からは、通常の対処としてドライブ全体の復号と再暗号化は示されていません。まずは累積更新を適用し、修正済みビルドへの到達を確認します。
ただし、回復キーの漏えいが疑われる場合や、未修正状態で端末が第三者の手に渡った場合は、通常のパッチ適用とは別に、キーの再生成やインシデント対応を検討する必要があります。
未修正端末を更新すれば、過去の盗難リスクも解消する
更新は将来の悪用可能性を下げますが、過去に第三者が端末を物理的に操作した事実を取り消すものではありません。
未修正状態で紛失や盗難が発生していた場合は、次の対応を検討します。
- 端末の無効化またはワイプ
- 利用者アカウントとセッションの失効
- 保存されていた認証情報の変更
- 回復キーや証明書の再発行
- ログとクラウドアクセス履歴の確認
- 情報漏えいとしての影響評価
固定ビルド以上への更新と物理対策を同時に進める
CVE-2026-50661は、物理アクセスを前提にBitLockerの保護機構を回避する脆弱性です。遠隔攻撃だけで成立するものではありませんが、ノートPCの紛失、盗難、共有スペースへの設置など、現実の運用では物理アクセスが発生する場面があります。
最初に実施すべきことは、対象端末のOSバージョンとフルビルドを確認し、次の基準以上へ更新することです。
- Windows 10 Version 22H2:19045.7548以上
- Windows 11 Version 24H2:26100.8875以上
- Windows 11 Version 25H2:26200.8875以上
- Windows 11 Version 26H1:28000.2525以上
- Windows Server 2022:20348.5386以上
- Windows Server 2025:26100.33158以上
ほかの対象バージョンについても、対応表の固定ビルド以上へ更新します。後続の累積更新を適用している場合は、最初の修正KBと番号が異なっていても問題ありません。
更新後は、manage-bde -statusまたはGet-BitLockerVolumeで保護が有効になっていることを確認します。あわせて、回復キーの集中保管、閲覧権限、物理的な端末管理、必要に応じたTPM+PINを点検してください。
CVEの修正はOSビルドで確認し、データ保護はBitLocker状態と回復キー管理で確認する。この2段階で対応することが、CVE-2026-50661への実務的な対策です。

コメント