CVE-2026-8863：當微軟簽署的合法引導程式成為系統後門

這些有漏洞的引導程式之所以能在市面上持續存在，是因為許多硬體和軟體廠商，當初為了自家的產品而從開源 shim 專案分支出程式碼，但後續卻從未進行更新。資安公司 Positive Technologies 已識別出具體的受影響產品，包括 WhiteCanyon WipeDrive（磁碟抹除工具）、Baramundi Management Suite（端點管理套件）、PC-Doctor Service Center（硬體診斷工具）以及芬蘭的大學入學考試 Abitti 系統 。這些第三方工具將它們過時的、由微軟簽署的 shim 安裝到 EFI 系統分割區（ESP）中，即便系統上的主要作業系統已完全修補，仍在電腦上留下一個永久的後門 。

攻擊手法：引導程式版的「自帶漏洞驅動」(BYOVD)

利用 CVE-2026-8863 並非能夠遠端直接發動的攻擊。威脅行為者必須先取得目標機器的系統管理員權限，或擁有修改開機流程的能力 。一旦取得這類存取權，攻擊者便會運用類似「自帶漏洞驅動程式 (BYOVD) 」的技巧。只不過，他們帶的不是驅動程式，而是將一個有漏洞但合法的微軟簽署 shim 引導程式，放入開機路徑中。

當系統在啟用 Secure Boot 的狀態下開機時，UEFI 韌體會檢查該 shim 的數位簽章，確認其有效（由受信任的 Microsoft UEFI CA 2011 憑證簽署）後便會執行它 。攻擊者隨後便能利用這個過時的 shim 來劫持開機流程，在 Windows 或任何安全軟體初始化之前載入惡意酬載。這將賦予他們在機器運作最早期階段的完全控制權，也就是所謂的任意預作業系統程式碼執行 。

預作業系統執行的風險：頑固難纏且難以清除

預作業系統程式碼執行的能力，正對應到 MITRE ATT&CK 框架中的技術 T1542.003——預作業系統啟動：Bootkit 。Bootkit 是一種在作業系統層級之下運作的惡意軟體，它能提供極其隱密的持久化機制，即使重新安裝作業系統也無法清除，還能躲避大多數傳統防毒軟體的偵測 。

成功透過 CVE-2026-8863 發動的攻擊，可讓攻擊者停用 BitLocker 磁碟加密、將惡意程式碼注入作業系統核心，或是建立一個在每次系統啟動時都會執行的持久化後門。修復 Bootkit 感染是出了名的棘手，通常需要完全刷新系統的 UEFI 韌體才能根除。這使得此漏洞即使在利用上需要本機存取權，依然是企業安全團隊的高度優先處理事項。資安公司 Rapid7 對此漏洞的風險評估為 CVSS v3.1 基礎分數 7.8，並將利用可能性歸類為「較低」，但其對機密性、完整性和可用性的技術性衝擊則被評為「高」。

UEFI 信任問題的歷史共業

CVE-2026-8863 並非單一事件，而是持續保衛 UEFI 開機程序安全戰役的最新篇章。其攻擊技巧與 2020 年的「BootHole」漏洞（CVE-2020-10713）相似，該漏洞同樣影響 GRUB2，可繞過 Secure Boot，當時需要大規模的 DBX 更新來修復 。而惡名昭彰的「BlackLotus」bootkit 也曾利用過 Windows 引導程式的缺陷，達成類似的預作業系統持久化效果 。

更雪上加霜的是，一場大規模的信任過期事件也同時在發生。用來簽署這些存在漏洞的 shim 以及無數其他第三方啟動元件的 Microsoft Corporation UEFI CA 2011 憑證，本身就在 2026 年 6 月 27 日到期 。微軟一直不斷推動整個生態系遷移到新的 2023 年憑證，這項複雜的工程對許多組織來說，在 CVE-2026-8863 被揭露的當下仍在進行中 。

補救措施與企業部署的注意事項

修復 CVE-2026-8863 並非一個簡單的 Windows Update 修補程式就能搞定。核心的緩解方案是進行 UEFI 禁止簽章資料庫（DBX）更新，也就是將存在漏洞的 shim 引導程式的加密雜湊值，加入韌體的撤銷清單中。一旦套用此更新，即使那些引導程式擁有合法簽章，UEFI 韌體也會拒絕執行它們 。

對企業 IT 和安全團隊而言，推行 DBX 更新需要審慎規劃：

1. 先導測試，再全面部署： 先將 DBX 更新部署到一個非生產環境的測試群組，以確保封鎖舊版 shim 不會導致任何關鍵系統無法開機，特別是那些可能默默地依賴於某個受影響之第三方引導程式的系統 。
2. 全面清查第三方引導程式： 使用資產盤點工具掃描 EFI 系統分割區，查看是否存在這些特定的脆弱引導程式。將盤點結果與 Positive Technologies 列出的產品清單進行交叉比對，包括磁碟抹除、系統管理和硬體診斷等工具 。
3. 驗證雙系統與 Linux 系統： 採用 Windows 與 Linux 雙系統開機的機器，尤其是那些使用較舊的 Linux 發行版，在套用 DBX 更新後被鎖住的風險極高。在強制執行撤銷前，務必確保所有已安裝的 Linux 發行版都已遷移到當前、無漏洞的 shim 引導程式 。
4. 與軟體供應商協調： 在封鎖舊版元件之前，聯繫任何已識別出受影響引導程式的供應商（如 WhiteCanyon 或 Baramundi），以取得更新、相容於 Secure Boot 的工具版本 。
5. 備妥 BitLocker 修復金鑰： 任何對 Secure Boot 組態的變更，都可能觸發 BitLocker 修復金鑰的提示。在部署 DBX 更新前，請確認修復金鑰已妥善備份，且服務臺人員能方便存取，以避免發生大規模鎖機事故。
6. 採用分階段更新環部署： 採用循序漸進的方式，從 IT 部門開始，然後是試點使用者，最後進行廣泛部署，並在每個階段都監控開機完整性問題。

CVE-2026-8863 這類漏洞是項沉重的提醒：Secure Boot 的防護強度，完全取決於它所信任的、由第三方簽署的程式碼生態系。對預啟動環境保持警覺的稽核，並迅速部署 DBX 撤銷更新，已成為維護平台完整性不可或缺的例行工作。