WinREのBitLocker回避 CVE-2026-45585

JPCERT/CC・CERT/CC（JVNVU#90386605 / VU#226679）が、Windows回復環境（WinRE）を悪用してUEFI/BIOSパスワードやBitLockerによるディスク暗号化を回避できる脆弱性 CVE-2026-45585 を公表しました。攻撃には端末への物理アクセスが前提で、ネットワーク越しに遠隔で悪用されるものではありません。とはいえ、紛失・盗難・置き忘れた業務端末の「中身は暗号化しているから大丈夫」という前提が崩れうる話で、情シスにとっては無視できない指摘です。

この記事でわかること

• CVE-2026-45585とは何か、なぜBitLockerが回避されうるのか
• 影響を受ける環境と、攻撃が成立する前提条件
• 情シスが取りうる現実的な緩和策（TPM+PINなど）と、公的指針の参照先

何が起きたのか

CVE-2026-45585は、Windowsの回復環境（WinRE: Windows Recovery Environment）を経由した起動経路が、通常のOS起動時と同じ認証・保護を一貫して強制しないことに起因する脆弱性です。攻撃者が端末に物理的に触れられる状況で、回復環境を呼び出して制限のないシェル（コマンド実行環境）に到達できると、管理者が設定したUEFI/BIOSパスワードや、構成によってはBitLockerによる保護をすり抜けられる可能性があります。

セキュリティ研究者により「YellowKey」という通称でも報じられており、特別に細工したファイルを外部メディアやEFIパーティションに配置し、WinREで起動して所定の操作を行うことで保護を回避する、という手口が示されています。いわゆる「Evil Maid（イービルメイド）攻撃」—一時的に端末を物理的に触れる者による不正改変—の典型例にあたります。

なぜBitLockerが「回避」されうるのか

BitLockerは多くの企業でTPM（Trusted Platform Module）と連携し、ユーザー操作なしに自動でロック解除する構成（TPM単独）で使われています。利便性は高い一方、「正しい端末で正規の起動経路を通れば自動で鍵が開く」という設計は、起動経路自体を攻撃者にすり替えられると弱点になりえます。今回の指摘は、その起動経路の一つであるWinREに保護の抜け穴があった、という構図です。BitLockerの暗号アルゴリズムが破られたわけではない点は、社内説明の際に正確に区別したいところです。

影響を受ける環境

報道・アドバイザリベースの情報では、WinREを利用できるWindows 10／11が広く対象とされ、新しめのWindows 11（24H2など）やWindows Server 2025（Server Coreを含む）でも影響が指摘されています。ファームウェア側の実装にも依存し、一部ベンダーのファームウェアが影響対象として挙げられています。最終的な影響範囲は各ベンダーの公式アドバイザリで確認してください。下表は現時点で整理できる要点です。

CVSSが「中程度」にとどまるのは、ネットワーク越しに自動拡散するタイプの脆弱性ではなく、物理アクセスという高いハードルがあるためです。スコアの数字だけで「大したことない」と判断せず、自社にとっての文脈—持ち出し端末の多さ、紛失・盗難の発生頻度—で危険度を読み替えることが大切です。

想定されるリスク：どんな組織が要注意か

この脆弱性が刺さるのは、次のような状況です。

• ノートPCを大量に持ち出す営業・現場部門があり、紛失・盗難が現実的に起こりうる
• 「BitLockerで暗号化しているから、紛失しても情報漏えいにはならない」と説明・運用してきた
• BitLockerをTPM単独（起動時のPIN入力なし）で運用している
• 退職者・委託先からの端末回収など、端末が第三者の手に渡る場面がある

逆に、データセンター内など物理的に厳重管理された端末だけなら、相対的にリスクは下がります。「どの端末が、どれだけ無人で第三者の手に届きうるか」が判断軸になります。

現場目線の課題

正直に言えば、こうした「物理アクセス前提」の脆弱性は、現場では後回しにされがちです。遠隔で一斉に悪用される脆弱性に比べて差し迫った感じが薄く、しかも対策はWinREイメージの修正やBitLocker構成の変更といった、全端末に手を入れる地道で重い作業になりがちだからです。WinREのイメージは既存端末では自動更新されず、Intuneやグループポリシーでの計画的な展開、あるいは手作業での対応が必要になる、という指摘もあります。

限られた人員で数百台・数千台の端末構成を一律に変えるのは簡単ではありません。だからこそ、後述の優先順位付け—「全部やる」ではなく「リスクの高い端末から」—が現実的な落としどころになります。

情シスはどうすべきか

まずは慌てて全台に手を入れる前に、一次情報で自社環境の該当性を確認するのが先決です。そのうえで、報じられている緩和の方向性は概ね次の2つです。

• BitLockerをTPM+PIN（起動時PIN入力）に切り替える：起動時にユーザーが知るPINを要求することで、端末を手に入れただけでは自動解錠されなくなります。既に暗号化済みの端末でもPowerShellやコントロールパネルから設定変更が可能とされています。利便性とのトレードオフは社内で要調整。
• WinREの保護・構成を見直す：運用上WinREが不要な端末では制限・無効化を検討。ベンダーが提示する修正手順（WinREイメージの更新等）に従う。

加えて、UEFI NVRAM変数（起動順序など）の改変制限、計測されたブート（Measured Boot）やセキュアブートの活用、そして端末の物理的な管理・持ち出しルールの徹底といった基本も効いてきます。技術対策と並行して、紛失・盗難時の初動（遠隔ロック・ワイプ、報告フロー）を改めて点検しておきましょう。

対策の優先順位付けやインシデント対応の基礎は、自前で長大なチェックリストを作るより、公的機関の指針を土台にするのが確実です。中小企業であればIPA「中小企業の情報セキュリティ対策ガイドライン」、インシデント対応の訓練にはIPAのインシデント対応 机上演習教材が参考になります。最新の正確な情報は、必ずJVN（JVNVU#90386605）およびCERT/CC（VU#226679）の一次情報、ならびにMicrosoft・端末ベンダーの公式アナウンスで確認してください。

中長期の視点：物理アクセスも「想定内」に

テレワークと端末の持ち出しが当たり前になった今、「社外で端末が第三者の手に渡る」前提は、もはや例外的な脅威ではありません。暗号化は重要な防御ですが、「暗号化していれば安全」という単純な等式は成り立たないことを、今回の件は改めて示しています。起動経路まで含めた端末の堅牢化と、紛失・盗難を前提にした運用設計（多要素の暗号解除、迅速な失効・ワイプ）を、中期の改善テーマとして据えておきたいところです。あわせて、利用者自身が端末から目を離さない・安易に放置しないという、地道なユーザー教育の積み重ねも欠かせません。

まとめ

• CVE-2026-45585はWinREを悪用し、UEFI/BIOSパスワードや構成次第でBitLockerを回避できる脆弱性。物理アクセスが前提で遠隔悪用はされない。
• 主リスクは紛失・盗難・回収端末。「暗号化しているから安全」という前提を点検すべき。CVSSは中程度だが、自社の持ち出し端末の実態で危険度を読み替える。
• 緩和はBitLockerのTPM+PIN化やWinRE構成の見直しが軸。まずはJVN／CERT/CCの一次情報とベンダー公式で該当性を確認し、リスクの高い端末から計画的に対応する。

出典

• JVN: Microsoft Windows Recovery EnvironmentにおけるUEFI/BIOSパスワード制限回避の脆弱性（JVNVU#90386605） https://jvn.jp/vu/JVNVU90386605/
• CERT/CC Vulnerability Note VU#226679 https://kb.cert.org/vuls/id/226679
• IPA 中小企業の情報セキュリティ対策ガイドライン https://www.ipa.go.jp/security/guide/sme/index.html

※CVSSスコアや一部の影響範囲は報道・二次情報を含みます。確定情報は上記一次情報および各ベンダー公式アナウンスをご確認ください。