跳至主要內容
ITD網站資安平台
ITD
搜尋

威脅情報

危急CVSS10.0#CVE-2026-72898#SQL 注入#Metabase#BI 工具

CVE-2026-72898 — Metabase 未驗證 SQL 注入漏洞可取得管理員權限（應變指南）

CVE-2026-72898 是 Metabase 密碼重設端點的未驗證 SQL 注入漏洞（CVSS 10.0、KEV）。提供修補版本、暫時性緩解措施與憑證輪替建議。

發布於 2026-08-22 更新於 2026-10-04 最後核實 2026-08-22 閱讀時間 3 分鐘
本頁內容

這是一份快速簡報，說明一個已確認在野外遭利用的漏洞（已列入 CISA KEV）。內容包括它做什麼、影響哪些對象，以及如何防禦性地應變，不含任何利用步驟。

公告摘要
CVE
CVE-2026-72898
嚴重性
嚴重 — CVSS 10.0（v3.1 與 v4.0 皆為此分數）
類型
未驗證 SQL 注入（CWE-89）
影響
取得 Metabase 執行個體的管理員權限，可觸及已連接資料庫的憑證與資料
受影響範圍
自行架設的 Metabase，x.58 版本線及之後、低於修補版本者
遭利用情況
已列入 CISA KEV（2026 年 8 月 11 日新增，到期日 8 月 14 日）；廠商表示此漏洞曾被當作 0-day 遭利用
主要修補方式
升級，並撤銷工作階段，同時輪替所有已連接資料庫的憑證
10.0
CVSS — 最高分
無需驗證
連線所需條件
管理員
可取得的權限
KEV
在野外遭利用

為何不能放著不管

利用此漏洞不需要任何驗證，而得手後可取得管理員權限，因此成為大規模無差別掃描的首要目標，這也是它在發布隔天就被列入 KEV 的原因。廠商表示，此漏洞在修補前已針對其自家雲端環境遭積極利用，因此「還沒有人來找我們」不是可以假設的前提。

漏洞是什麼

Metabase 是一個 BI 與分析平台，會連接您的資料庫，並在其上提供儀表板與查詢服務。此缺陷在於：處理密碼重設的端點會以呼叫者提供的值組成 SQL。這段處理發生在驗證之前，因此攻擊者不需要任何帳號（SQL 注入，CWE-89）。

注入的目標是 Metabase 自身的應用程式資料庫，其中保存使用者、工作階段、API 金鑰與連線設定，也就是該執行個體的控制權。CISA 的 KEV 條目指出，攻擊者取得管理員權限後，可以變更應用程式設定、竊取已連接資料庫的已儲存憑證、讀取透過這些連線可存取的任何資料，並將其匯出。

未經驗證的攻擊者

↓ 透過密碼重設端點注入 SQL

Metabase 應用程式資料庫 → 管理員

↓ 已儲存的連線設定與憑證

每個已連接的資料庫

營收、客戶、紀錄——BI 可讀取的所有資料

BI 工具的管理員權限，等同於取得所有已連接資料庫的憑證，因此損害不會停留在該工具本身。

受影響對象

項目說明
受影響範圍自行架設的 Metabase；廠商表示 Metabase Cloud 已完成修補
易受攻擊版本x.58 版本線及之後、低於修補版本者
修補版本0.58.24 / 0.59.21 / 0.60.17 / 0.61.11 / 0.62.9 / 0.63.5（Enterprise：1.58.24 / 1.59.21 / 1.60.17 / 1.61.11 / 1.62.9 / 1.63.5）
前提條件無——不需驗證
影響取得管理員權限 → 已連接資料庫的憑證與資料
暫時性緩解措施封鎖 /api/session/reset_password 端點（僅為升級前的暫時措施）

應該怎麼做

1

升級至修補版本（第一優先，也是唯一真正的修補）

取得您所用版本線的修補版本，然後確認實際在執行的版本。「我們已經升級了」但舊映像檔仍在提供服務，是這裡最常見的失誤。
2

若尚無法升級，先封鎖該端點

廠商的緩解方式是在反向代理或 WAF 封鎖 /api/session/reset_password。請嚴格將其視為暫時措施。
3

撤銷所有工作階段，接著稽核 API 金鑰與管理員

廠商升級後的步驟包括：刪除應用程式資料庫中 core_session 資料表的所有資料列以結束每個工作階段，移除您不認得的 API 金鑰，並檢查管理員帳號是否有無法解釋的變更。若有人取得過管理員權限，單靠升級無法移除他們建立的帳號與金鑰。
4

輪替所有已連接資料庫的憑證（請勿跳過）

廠商明確強調此步驟。請將該工具持有的每一組連線憑證都視為已遭取得。同時檢視資料倉儲紀錄，以及 Metabase 的查詢與活動歷史紀錄。
5

減少可被連線的範圍

不要把 BI 工具直接暴露在網際網路上，應置於 VPN、IP 白名單或內部網路之後。當缺陷位於驗證之前的程式碼中時，您的驗證強度就不重要了。無法被連上的系統，就無法被攻擊。營運面的步驟請參閱漏洞應變實務。

廠商公布的偵測提示

廠商將利用模式描述為：對 /api/session/reset_password 的呼叫回傳 400，緊接著 /api/user/current 回傳 200。若您仍保有存取紀錄，值得檢查是否出現這樣的序列。若沒有任何紀錄，答案是「未知」，而非「乾淨」。在這種情況下，請假設已遭入侵，並執行第 4 步。

本站觀點：BI 工具保存了所有已連接的憑證，因此應以保護最敏感資料庫的等級來防護

組織往往把 BI 與分析工具歸類為「顯示資料的東西」，並以低於資料庫本身的防護等級來管理。實際情況恰好相反：此工具是單一集中保存所有所連接系統憑證的地方。本站的立場是，它應該以其背後最敏感資料庫的等級來防護。具體來說：為 BI 設定最小權限的連線使用者（唯讀，且只涵蓋其所需的 schema），絕不直接暴露於網際網路，並在需要之前就備妥憑證輪替的操作手冊。做到這些，即使發生最糟的情況，例如驗證之前的程式碼出現缺陷，損失的也只是一組連線，而不是每個資料庫。

資料來源

延伸閱讀

FAQ

QCVE-2026-72898 允許什麼行為？
A

遠端、未經驗證的攻擊者可透過 Metabase 密碼重設端點注入任意 SQL，並取得該執行個體的管理員權限。根據 CISA 的說明，攻擊者由此可以變更應用程式設定、竊取已連接資料庫的已儲存憑證、讀取透過這些連線可存取的任何資料，並將其匯出。

Q最終的修補方式是什麼？
A

請升級至您所用版本線的修補版本：0.58.24、0.59.21、0.60.17、0.61.11、0.62.9 或 0.63.5（以及對應的 1.x Enterprise 版本）。如果無法立即升級，廠商提供的暫時性措施是封鎖 /api/session/reset_password 端點，但這應視為升級前的暫時措施，而非修補。

Q只要升級就足夠了嗎？
A

不夠。廠商在升級後的說明包括：刪除應用程式資料庫中 core_session 資料表的所有資料列以撤銷每個工作階段、移除您不認得的 API 金鑰、稽核管理員帳號，並輪替所有已連接資料庫的憑證。如果攻擊者取得過管理員權限，請假設這些資料庫憑證已落入其手中。

QMetabase Cloud 呢？
A

廠商表示，Metabase Cloud 執行個體已先行升級並修補。受影響的是自行架設的部署環境。