編按：本文綜合整理自 Ars Technica 報導、ESET 官方研究報告與 CERT/CC VU#616257 漏洞公告，並加入 Siami 編輯部觀點與分析。
漏洞背景：Secure Boot 與 shim 的設計初衷
微軟於 2012 年隨 Windows 8 推出 Secure Boot 機制，作為「統一可延伸韌體介面（UEFI）」內建的安全機制，目的是在作業系統啟動前阻擋未經授權的韌體與開機載入器。對 Linux 社群而言，shim 是一段由紅帽工程師維護的小型開機載入器，作為中介層讓 Linux 發行版能沿用微軟的 Secure Boot 信任鏈。微軟負責審核與簽署這些 shim，使廠商與企業軟體（如救援工具、磁碟加密程式）能在不違反 Secure Boot 原則的情況下啟動。
換句話說，shim 是 Windows 與 Linux 共同信賴的「根憑證」之一。一旦 shim 出問題，影響範圍涵蓋所有依賴 UEFI 的裝置。
ESET 的發現：11 個被遺忘的有缺陷 shim
斯洛伐克資安公司 ESET 的研究人員 Martin Smolár 在 2026 年 7 月 14 日發表的研究報告中指出，至少有 11 個微軟簽署的 shim 映像檔存在可利用漏洞，其中最早一個可追溯至 2013 年。這些映像檔在被研究人員回報漏洞後，微軟並未如預期般「撤銷」它們的簽章；它們至今仍可從 Microsoft 第三方簽署伺服器合法取得。
技術細節：shim 內嵌一個 SBAT（Secure Boot Advanced Targeting）世代編號政策，原本可在每次安全更新時遞增「最低可接受世代」，自動把過舊的開機元件擋在門外。然而這套機制僅對「版本世代」有效，對於「映像檔本身的可利用漏洞」並無主動防護能力。
這些「被遺忘」的有缺陷 shim 包括：
- Oracle shim：簽署的次級開機元件含 CVE-2015-5381（緩衝區溢位漏洞），攻擊難度低。
- 多個廠商 shim：未實作 MOK deny-list 強制執行與 SBAT 政策強制執行，而這兩項機制都是 shim 發布之後才加入的強化措施。
- 其他 shim：本身程式碼含有漏洞，且微軟未撤銷其簽章。
攻擊手法：初階駭客也能執行
研究人員指出，整套繞過手法的技術門檻低到令人不安。攻擊者只需：
- 取得其中一個有缺陷的 shim（例如從微軟的合法簽署管道下載）。
- 將其部署到目標機器的 UEFI 開機路徑。
- 利用該 shim 已知漏洞載入任意未簽署的開機程式。
成功後，惡意程式可在作業系統啟動之前取得最高權限，並在作業系統完全不知情的情況下長期潛伏。這類「bootkit」比傳統 rootkit 更加危險，因為：
- 作業系統重灌無效：bootkit 存在於韌體層，重新安裝 Windows 並不會清除。
- 防毒軟體看不到：Secure Boot 失效後，作業系統內任何掃描工具都無法偵測。
- 即使 Secure Boot 開啟也無用：因為繞過是利用 shim 本身，不是關閉 Secure Boot。
🚨 為什麼這件事重要
這次揭露的漏洞之所以震撼業界，有三個關鍵層面：
第一，影響範圍史無前例。Secure Boot 從 2012 年推出至今已 14 年，幾乎所有 2012 年後生產的 UEFI 裝置都內建這套機制，從一般消費筆電、桌機、伺服器到工業控制設備無一倖免。研究人員寫道，這等於 Secure Boot 存在的 14 年中有 13 年都是「紙老虎」。
第二，攻擊手法過於簡單。ESET 明確指出，執行此繞過的「技術門檻低到足以被初階駭客輕易執行」。這意味著攻擊者不必是國家級 APT 組織、不必花大錢買零日漏洞，任何稍微有技術能力的人都能在公開網路取得完整的攻擊鏈。2023 年 ESET 揭露的 BlackLotus UEFI bootkit 是首個在野外被觀察到利用此類攻擊的惡意程式，當時就引起全球恐慌；如今這批漏洞直接讓類似攻擊變得「平民化」。
第三，修復並不完整。即使微軟已在 2026 年 6 月的安全更新中撤銷這 11 個 shim 的簽章，但研究人員強調，撤銷並不能解決所有問題。已經被植入 bootkit 的裝置依然處於受感染狀態；Linux 用戶需要透過 Linux Vendor Firmware Service（LVFS）或各家發行版的更新機制取得修補；而未來若有更多未列入本次研究的舊 shim 被發現，問題還會捲土重來。
🚨 數據解讀與質疑
ESET 公開的數字顯示，11 個有缺陷的 shim 中：
- 最老的來自 2013 年，意味著問題在 Secure Boot 推出僅一年後就出現。
- 其中 1 個（CVE-2015-5381）影響的 Oracle shim，攻擊難度被列為「低」——這是 CVSS 評分中代表「無須特殊條件、可遠端利用」的等級。
- 微軟在 2026 年 6 月才撤銷這些簽章，從漏洞被回報到撤銷，間隔最長可能長達 13 年。
值得追問的是：微軟為何遲遲不撤銷這些已知有缺陷的映像檔？常見猜測包括：
- 依賴關係複雜：撤銷 shim 可能會同時癱瘓大量仰賴它的企業軟體（如磁碟加密、系統救援工具），微軟可能擔心破壞相容性而猶豫不決。
- 流程缺失：微軟的 UEFI 簽署流程可能缺乏「發現漏洞 → 主動撤銷」的自動化機制。
- 責任歸屬模糊：shim 雖由微軟簽署，但程式碼由紅帽等 Linux 社群維護，雙方對「誰該負責撤銷」可能缺乏明確協議。
另一個更深層的問題是：UEFI 信任鏈的設計根本性缺陷。Secure Boot 把信任根放在「憑證」而非「程式碼行為」，只要憑證有效，無論背後的程式碼多老多有缺陷，都會被放行。這是一個從設計之初就存在的結構性問題，並非微軟「疏失」可以解釋。
業界反應與後續修補建議
ESET 已於 2026 年 6 月將漏洞通報 CERT/CC（編號 VU#616257），並協助微軟進行撤銷作業。CVE-2026-8863 是本次事件的正式漏洞編號。
Windows 用戶：
- 安裝 2026 年 6 月以後的 Windows 更新即不受新攻擊影響。
- 若懷疑裝置已被植入 bootkit，需要重新刷新 UEFI 韌體（刷 BIOS），無法單靠作業系統重灌解決。
Linux 用戶：
- 透過 Linux Vendor Firmware Service（LVFS）檢查更新。
- 使用
uefi-dbx-audit腳本驗證 shim 撤銷狀態。 - Fedora、Ubuntu、Debian 等主流發行版的最新 ISO 已內建修補過的 shim。
企業 IT：
- 部署 Secure Boot 政策時，務必啟用 SBAT 政策強制執行。
- 對高敏感裝置考慮加設開機密碼（BIOS 密碼）作為第二層防護。
- 定期稽核裝置的 UEFI 開機鏈是否使用已撤銷的元件。
結語
這次揭露的事件提醒所有人：沒有任何安全機制是「設定後就不用管」的終身保險。微軟 Secure Boot 推出 14 年，期間一直是被視為 UEFI 安全基石的標準配備，如今卻被證實其中 13 年都存在可被輕易繞過的後門。
未來類似揭露只會越來越多——隨著研究人員持續對 UEFI 生態系進行逆向工程，過去被視為「可信」的元件很可能一一被揭穿是「長期未被仔細檢視的紙老虎」。對一般使用者與企業 IT 而言，把 Secure Boot 當成唯一一道韌體防線的心態，必須徹底改變。
編按：本文綜合整理自 Ars Technica、ESET 官方研究報告、CERT/CC VU#616257 漏洞公告、SentinelOne 漏洞資料庫，以及 The Hacker News 等業界報導，並加入 Siami 編輯部觀點與分析。技術細節以 ESET 研究員 Martin Smolár 公布的內容為主要依據。
網友熱門留言 (4)