UEFI 開機漏洞評分 9.5　全球伺服器首當其衝

9.5 分。這是 CVE-2026-97631 的嚴重程度評分，滿分 10 分。漏洞不在應用程式，也不在作業系統，而在伺服器開機時最先執行的 UEFI 韌體。全球大多數伺服器供應商與數據中心都用上這套開機碼，包括香港機櫃裡那些跑銀行、交易所、醫院外判系統的機器。

漏洞位於 TianoCore EDK II 的 ICMP 元件，屬記憶體腐敗問題。攻擊者可在作業系統載入前執行惡意程式碼，時間點在 Secure Boot 建立信任鏈之前，連信賴平台模組（TPM）的載入流程都未開始。傳統防毒與端點偵測在這個階段根本未啟動。

9.5 分漏洞藏在開機第一秒

CVE-2026-97631 的 9.5 分不是象徵式評分。它位於 TianoCore EDK II 的 ICMP 元件，屬記憶體腐敗類漏洞，攻擊者可以透過它執行惡意程式碼，而且是在作業系統與韌體防護機制生效之前。換句話說，機器一按電源，攻擊窗口就已經打開。

UEFI Forum 一名代表去年曾稱 EDK2 是 UEFI 規格的「首要方案」。這句話如今讀來格外刺眼。EDK2 是開源參考碼，硬件廠商與雲端商拿它來砌出自家 UEFI 韌體，等於同一條根支撐全球大量開機流程。漏洞一現，影響面以「行星級」來形容。

受影響環節涵蓋 Secure Boot 建立信任鏈之前的階段，包括 TPM 載入流程。攻擊者若在此階段落地，事後在作業系統層做的日誌與鑑證可能已經失去意義。這是這條漏洞最難處理的地方：防護與偵測的起跑線，被推到開機第一秒之前。

幾乎所有 UEFI 供應商都中招。AMI、Insyde、Phoenix 三家主要獨立 BIOS 供應商都大量採用 EDK2 參考碼，報道明確點名三者。硬件廠商與雲端商向它們取貨，等於漏洞隨韌體批次流入機房。全球大多數伺服器供應商與數據中心都使用相關開機韌體。

連標榜強化的分支都未能倖免。微軟的 Project Mu 是 EDK2 的加固分支，但報道指它亦包含含漏洞的元件。這打破一個常見假設：以為選用「加固版」韌體就等於多一層保險。加固分支與上游參考碼的關係，比採購部門想像中緊密。

香港的數據中心與雲端服務高度集中，銀行、交易所、醫院外判系統不少跑在本地機櫃。企業要問的是：資產清單有否記錄每台機的 UEFI 供應商與版本？外判商是否承諾在廠商修補推出後 30 日內完成更新？採購合約有否寫明韌體更新責任誰屬？這些問題今日未有標準答案。

端點偵測與防毒軟件要等作業系統載入後才啟動，但 CVE-2026-97631 的惡意程式碼在開機韌體階段已執行完畢。EDK2 的 ICMP 元件記憶體腐敗問題，讓攻擊者可以在 Secure Boot 建立信任鏈之前搶先運行，防毒掃描根本無機會介入。

攻擊者藉此建立持久化載荷，即使重裝系統亦未必清除。惡意程式碼可藏於韌體更新區或周邊裝置的選項唯讀記憶體，作業系統層的清除工具掃描不到。企業慣用的「重裝解決一切」思維，在這類開機前漏洞面前失效。

素材未披露最終載荷細節與實際利用案例，暫時難以判斷是否已有在野攻擊。Ars Technica 的報道在「While final payloads」處中斷，未交代攻擊者實際部署什麼。這個空白令風險評估更難，企業只能假設最壞情況。

漏洞在開源碼，但修補要經晶片商、BIOS 供應商、伺服器廠、雲商四層傳遞。AMI、Insyde、Phoenix 三家獨立 BIOS 供應商都廣泛使用 EDK2 參考碼，微軟的 Project Mu 分支亦包含含漏洞的元件。每層整合、測試、發布都可能拖延，企業難以自行判斷手上機器是否受影響。

企業需要依賴資產清單與廠商公告，但多數機構的資產記錄只到伺服器型號，未必記錄每台機的 UEFI 供應商與韌體版本。香港數據中心營運商若要清查，得逐台機器向伺服器廠查詢 BIOS 來源，過程繁複。採購合約有否寫明韌體更新責任誰屬，今日未有標準答案。

香港營運商會否在採購合約加入韌體更新時限條款，將決定事故應變速度。金管局與個人資料私隱專員公署的通報時限，在開機前漏洞面前變得更難滿足——事後日誌可能被抹除，連攻擊痕跡都找不到。這些問題今日未有標準答案，但供應鏈每一層的拖延都會壓縮應變窗口。

這條 9.5 分漏洞的殺傷力在於「開機前」執行，傳統防毒與端點偵測幫不上忙。香港數據中心與雲端服務高度集中，銀行、交易所、醫院外判系統不少跑在本地機櫃，一旦被利用，事後日誌可能被抹除，通報時限更難滿足。

企業要問的是：資產清單有否記錄每台機的 UEFI 供應商與版本？外判商是否承諾在廠商修補推出後 30 日內完成更新？採購合約有否寫明韌體更新責任誰屬？這些問題今日未有標準答案，但唔問，風險只會繼續被低估。