英語版で読む
技術 約7分で読めます

MicrosoftがYellowKey CVE-2026-45585にWinRE改修とTPM+PINの緩和策を公開

セキュリティ Microsoft Windows 脆弱性 CVE
いけさん目次

TL;DR

影響 Windows 11 24H2 / 25H2 / 26H1（x64）、Windows Server 2025 / Server Core。攻撃ベクトルはUSBに加えEFIシステムパーティション

CVE CVE-2026-45585、CVSS 6.8 Important、Exploitation More Likely / Exploited: No

対応 WinREイメージ内 BootExecute から autofstx.exe を削除、TPM-only端末はTPM+PINへ切替

留保 Chaotic Eclipse側はTPM+PINもバイパスするPoCを保留中と主張。恒久パッチ提供時期は未公表

YellowKeyに CVE-2026-45585 が付き、Microsoftがパッチ前の緩和策を出した。
前回のYellowKeyとGreenPlasmaの記事を書いた時点では、YellowKeyは未パッチ・CVE未割当て・公式緩和策なしだった。
今回変わったのは、Microsoftが「修正パッチまでの間にやる作業」をMSRCで明文化した点だ。

MSRCの評価は Important、CVSS 6.8。
攻撃ベクトルは Physical、つまり物理アクセスが前提になる。
一方で、機密性・完全性・可用性はいずれも High で、成功時にはBitLocker Device Encryptionで保護されたシステムドライブ上のデータへ到達できる、という扱いになっている。

The Hacker Newsが引用している影響対象は、Windows 11 24H2 / 25H2 / 26H1 のx64版、Windows Server 2025、Windows Server 2025 Server Core。
前回の公開PoC周辺ではWindows Server 2022も対象として語られていたが、今回のMSRCベースの案内でまず合わせるべきなのはこの対象一覧になる。

攻撃ベクトルについても、前回時点ではUSBメモリ経由の話に集中していたが、今回のMSRC公開と各メディア続報で EFIシステムパーティション側にFsTxファイルを置く経路 も含まれることが明示された。
USBが必要というシナリオよりも前提が緩く、管理者権限などで一時的にEFIパーティションに書き込めれば、後から物理アクセスだけで発火させられる構図になる。

WinRE内のautofstx.exeを自動起動させない

Microsoftが出した緩和策の核は、WinRE（Windows回復環境）イメージをマウントして、レジストリの BootExecute から autofstx.exe を外す作業だ。
autofstx.exe はFsTx Auto Recovery Utilityで、Transactional NTFSの回復処理に関係する。

YellowKeyは、WinRE起動時に外部ボリューム側のFsTx関連データが処理され、回復環境の起動内容がずれるところを突いていた。
Will Dormannは、この変更によってTransactional NTFSのreplayが winpeshl.ini を消す流れが止まる、と説明している。

Microsoftの手順は、おおまかにはこういう流れになる。

作業対象
reagentc /mountre端末上のWinREイメージをマウント
reg loadマウントしたWinRE内のSYSTEM hiveを読み込む
BootExecute 編集HKLM\WinREHive\ControlSet001\Control\Session Manager から autofstx.exe を削除
reagentc /unmountre /commit変更をWinREイメージへ反映
reagentc /disable と reagentc /enableBitLockerとWinREの信頼関係を作り直す

この作業は通常のWindows Update適用とは違い、端末ごとのWinREイメージを直接触る。
Intuneや構成管理ツールで配る場合でも、「OSにパッチを当てたら終わり」ではなく、WinREイメージの状態確認まで含めた運用になる。

ここで押さえておきたいのは、Will Dormannが指摘している根本構造の話だ。
彼はInfosec Exchangeへの投稿で、「あるボリュームの \System Volume Information\FsTx ディレクトリが、replay時に別のボリュームの中身を書き換えられること自体が問題に見える」という趣旨を書いている。
autofstx.exeをBootExecuteから外せば winpeshl.ini 削除という具体的な悪用経路は止まるが、「外付けボリュームのトランザクションログがWinRE内部ボリュームに作用できる」というFsTxの設計面はそのまま残る。
今回のMSRC緩和策はトリガーをひとつ塞ぐ位置付けで、Transactional NTFSのreplay経路そのものを設計レベルで作り直す話ではない。

TPM-only BitLockerにはPINを足す

もう1本の緩和策は、TPM-onlyのBitLocker構成にstartup PINを追加すること。
既に暗号化済みでTPM-only protectorを使っている端末では、PowerShellなら Add-BitLockerKeyProtector C: -TpmAndPinProtector、cmdなら manage-bde -protectors -add C: -TPMAndPIN を使う案内になっている。

PIN設定が出てこない端末では、グループポリシーの Require additional authentication at startup を有効化し、Configure TPM startup PIN を Require startup PIN with TPM に変える。
未暗号化端末では、Intuneまたはグループポリシーで同じ条件を先に入れてからBitLockerを有効化する。

ここでの判断は、単に「PINを足すか」ではなく、盗難・一時持ち出し・修理委託・検査で端末を手元から離す前提があるかどうかだ。
TPM-onlyは利用者の入力なしに起動できるので運用は軽い。
その代わり、物理アクセス前提のBitLockerバイパスでは真っ先に確認対象になる。

ただし、このTPM+PINへの切り替えがどこまで通用するかについて、Chaotic Eclipse側が留保をつけている点も書いておきたい。
The Hacker NewsとHelp Net Securityの報道では、研究者本人が「TPM+PIN構成もバイパスできる別のPoCを手元に持っており、現時点では公開を止めている」と発言したとされている。
今回のYellowKey（CVE-2026-45585）はあくまでTPM-only相当の構成を破る話で、TPM+PINへの切り替えはMSRCが案内している直接の緩和策ではあるが、Chaotic Eclipseの主張が正しければ「TPM+PINに移したから恒久的に安全」という整理にはならない。
盗難・没収シナリオで脅威モデルが重い端末ほど、TPM+PIN化と並行して、回復キーのエスクロー先・WinREへのアクセス可否・端末紛失検知の運用まで見直す。

まだパッチではない

MSRCは、このCVEを「security updateが利用可能になるまでの緩和策を提供するため」に発行した、と説明している。
つまり、2026年5月21日時点では恒久修正ではない。
MicrosoftのExploitability評価も Exploitation More Likely になっており、公開PoCがある前提で扱われている。

ただし、MSRC上の悪用状況は Exploited: No。
現時点で確認されているのは公開PoCと独立研究者による再現で、実際の攻撃で使われたというMicrosoft側の確認は出ていない。

Microsoftはアドバイザリの中で、本件について「YellowKeyとして公表されたWindowsのセキュリティ機能バイパス脆弱性を認識しており、本脆弱性のPoCは公開され、協調的脆弱性開示のベストプラクティスに反している」という趣旨のコメントを出している。
RedSunサイレント修正を起点にした研究者側との対立は、CVE付与と公式緩和策の公開によって完全には収まっていない。
恒久パッチの提供時期は本稿執筆時点では未公表で、6月Patch Tuesday以降のリリースで扱われるかどうかはまだ確定していない。

この差は運用上そこそこ大きい。
紛失端末・持ち出し端末・高機密端末はWinRE改修とTPM+PINのどちらかを早めに当てる。
物理アクセスを厳しく管理できる据え置き端末では、緩和策の副作用を検証してから段階配布する余地がある。

前回記事から変わったところ

前回記事では、YellowKeyを「未パッチで公式緩和策なしの公開PoC」として扱った。
その時点では、WinRE無効化やTPM+PIN、物理セキュリティ強化が当面の自衛策だった。

今回のMSRC公開で、判断軸はかなり具体化した。

前回時点今回
CVEなしCVE-2026-45585
公式緩和策なしWinRE内 autofstx.exe 無効化手順あり
TPM+PINは暫定案MicrosoftがTPM-onlyからTPM+PINへの変更を明示
対象は報道・PoCベースWindows 11 24H2/25H2/26H1、Server 2025系として案内

YellowKeyはBitLockerの暗号を解く攻撃ではなく、WinREの起動経路で保護済みボリュームへ到達する攻撃だ。
だから緩和策も「暗号方式を変える」ではなく、「WinRE内でFsTx自動回復を走らせない」「起動時にPINを要求する」に寄っている。

YellowKeyについて手を動かす対象も、PoC再現からWinREイメージとBitLocker protector構成の確認に移った。

参考