CVE-2026-50661のBitLocker回避を解説|対象OS・修正KB・確認手順

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 VectorPhysical攻撃者が対象端末を物理的に操作する必要がある
Attack ComplexityLow前提を満たした後の攻撃難度は低いと評価されている
Privileges RequiredNoneWindowsアカウントなどの事前権限を必要としない
User InteractionNone利用者にファイルを開かせるなどの操作を要求しない
ConfidentialityHigh情報の機密性に大きな影響を与える可能性がある
IntegrityHighデータやシステムの完全性に大きな影響を与える可能性がある
AvailabilityNone可用性への直接的な影響は評価されていない

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 160714393.9339未満KB509953514393.9339
Windows 10 Version 180917763.9020未満KB509953817763.9020
Windows 10 Version 21H219044.7548未満KB509953919044.7548
Windows 10 Version 22H219045.7548未満KB509953919045.7548
Windows 11 Version 24H226100.8875未満KB510165026100.8875
Windows 11 Version 25H226200.8875未満KB510165026200.8875
Windows 11 Version 26H128000.2525未満KB510164928000.2525

Windows 11については、公開された影響範囲に24H2、25H2、26H1が記載されています。Windows 11という製品名だけで判断せず、バージョンとビルドを確認してください。(NVD)

Windows Server

OS影響を受けるビルド2026年7月14日の初回修正KB修正済みビルド
Windows Server 201614393.9339未満KB509953514393.9339
Windows Server 201917763.9020未満KB509953817763.9020
Windows Server 202220348.5386未満KB509954020348.5386
Windows Server 202526100.33158未満KB509953626100.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について未修正とは限りません。(マイクロソフトサポート)

確認時は次の順番で判断すると誤りを防げます。

  1. OSの製品名とバージョンを確認する
  2. フルビルド番号を確認する
  3. 対応する固定ビルド以上か比較する
  4. 補助情報として更新履歴のKB番号を確認する

自分のPCやサーバーが修正済みか確認する手順

Windowsの画面から確認する

最も簡単なのは、winverを実行する方法です。

  1. WindowsキーとRキーを押す
  2. 「ファイル名を指定して実行」にwinverと入力する
  3. 表示されたバージョンとOSビルドを確認する
  4. 対応表の固定ビルド以上か比較する

たとえば、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 StatusFullyEncrypted
Encryption Percentage100
Protection StatusOn
Key ProtectorTPM、回復パスワード、必要に応じてTPM+PIN

「暗号化済み」と「保護が有効」は同じではありません。ボリュームが100%暗号化されていても、BitLockerの保護が一時停止されている場合は、Protection StatusOffになります。

つまり、次の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無効・一時停止の端末更新に加えて暗号化ポリシーを是正
インシデント対応未修正状態で紛失・盗難された端末更新作業ではなく、侵害を想定した対応へ移行

実務では、次の順序で進めると確認漏れを防げます。

  1. Windows 10、Windows 11、Windows Serverの端末一覧を抽出する
  2. OSバージョンとフルビルドを収集する
  3. 固定ビルド未満の端末を抽出する
  4. 持ち出し端末と物理的に触れやすい端末を優先する
  5. 2026年7月の更新または後続累積更新を配信する
  6. 再起動後にフルビルドを再取得する
  7. BitLockerのProtection Statusを確認する
  8. 回復キーが管理基盤に保管されているか確認する
  9. 更新失敗端末と長期オフライン端末を例外一覧に残す
  10. 紛失済み端末はセキュリティインシデントとして別管理する

管理台帳に残すべき項目

更新作業の完了判定は、「更新を配信した」ではなく「端末が固定ビルド以上になった」で行います。

最低限、次の項目を記録します。

項目
端末名PC-00123
利用者・設置場所営業部・持ち出し
OSWindows 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への実務的な対策です。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次