Metabase CVSS 10 零時差漏洞遭主動利用：Framework 客戶姓名、登入 IP、電話與完整地址外洩

編按：本文綜合整理自 Metabase 官方資安公告、GitHub 官方安全公告 GHSA-vwf4-m7j8-wcjf、Framework 客戶通知與社群討論及 Hacker News 討論串，並加入 Siami 編輯部觀點與分析。

開源商業智慧平台 Metabase 證實，一個 CVSS 10.0 的零時差漏洞已遭攻擊者主動利用。模組化筆電廠商 Framework 隨後確認，自家 Metabase Cloud instance 確實遭未授權存取，客戶姓名、電子郵件、登入 IP、電話，以及完整帳單與配送地址都在受影響欄位內。Framework 表示，目前未發現訂單與付款資料遭讀取，但第三方鑑識仍在進行，現階段結論屬於初步調查。

事件時間線：8 月 3 日入侵，Framework 收到通知後約六小時告知客戶

Metabase 表示，公司在美國時間 8 月 3 日發現 Cloud 服務遭攻擊，攻擊者利用的是版本 1.58 以上當時尚未公開的漏洞。Metabase 隨即封鎖被利用的端點、辨識根因並完成修補，也通報執法機關、委託第三方鑑識公司調查。

8 月 6 日上午 9 時（太平洋時間），Metabase 通知 Framework：該公司的 instance 不僅曾處於可被利用狀態，而且日誌顯示攻擊者已實際進入。Framework 查核 Metabase 提供的 application logs 後確認事件，旋即輪替所有與 Metabase 連線的資料庫憑證，並檢查管理員帳號及其他系統的存取狀態。

Framework 客戶社群記錄顯示，第一批通知約在收到 Metabase 告警後六小時送出。這個速度受到不少使用者肯定，但也有使用者指出，快速通知只代表事件應變做得好，不能回答「為何 BI 平台原本能取得如此完整的個人資料」。

Framework 的通知列明：事件目前不含訂單或付款資料，但調查尚未完成；若 Metabase 後續提供影響客戶的新資訊，Framework 仍會寄送更新。

漏洞如何運作：未登入也能 SQL 注入，直接跨到管理員權限

GitHub 官方安全公告將漏洞編為 GHSA-vwf4-m7j8-wcjf；截至發稿時尚未配置 CVE 編號。其 CVSS 3.1 分數為滿分 10.0，向量是 AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H，代表攻擊可從網路發動、複雜度低、不需任何既有權限，也不需要受害者點擊或互動。

漏洞位於公開可達的 /api/session/reset_password 流程。攻擊者可以向 Metabase application database 注入任意 SQL，進而取得 Metabase 管理員權限。這不是只能看見一張 dashboard 的小漏洞；取得管理員能力後，可能產生一整條橫向風險鏈：

• 更改 Metabase 應用程式設定與新增管理員帳號
• 讀取 Metabase 儲存的連線資料庫憑證
• 存取那些憑證原本可讀取的資料倉儲內容
• 執行查詢並匯出資料
• 建立持續有效的 session 或 API key

Metabase 已明確確認漏洞遭主動利用。Cloud 客戶的服務已由官方自動修補；自行架設的使用者則必須自己更新、查核日誌並進行憑證輪替，不能因套件已發布修補就假設過去沒有遭入侵。

Framework 確認哪些資料被讀取

Framework 根據 Metabase 提供的日誌，確認攻擊者存取了下列欄位：

• 客戶完整姓名與電子郵件地址
• 登入 IP 位址
• 帳單及配送地址，包括國家、城市、州、省或行政區、郵遞區號
• 電話號碼與公司名稱
• Framework for Business 客戶可能另涉及公司電話、VAT、EIN 與帳務電子郵件；這部分仍在調查

Framework 強調，現有證據未顯示訂單資訊或付款資料遭存取。其隱私政策也顯示付款由 Stripe 處理，因此信用卡資料並非這次已確認外洩清單的一部分。不過，「沒有卡號」並不等於風險很低：姓名、品牌關係、住址、電話、登入 IP 與配送情境組合起來，足以讓攻擊者製作比一般垃圾信精準得多的社交工程攻擊。

其中一位正等待筆電出貨的使用者指出，冒充 Framework 的「付款方式需更新」「進口費待繳」或「配送異常」通知，外觀可與正常流程極為相似。另一位使用者甚至沒有完成購買，只曾填入地址查看含運價格，仍收到外洩通知，顯示進入分析系統的資料範圍不只已付款訂單。

🚨 為什麼這件事重要：BI 平台已成為企業個資的隱形副本

這起事件的關鍵，不只是 Framework 客戶受到影響，而是揭露現代企業常見卻不容易被消費者看見的資料流：原始交易系統保存一份資料，客服、CRM、行銷、BI 與雲端資料倉儲又各自保存或能查詢另一份。每增加一個能讀取完整個資的系統，就增加一個可被攻擊的入口；供應商的供應商也可能成為風險來源。

Metabase 是為了分析而存在的工具，但許多分析需求只需要匿名 ID、國家或城市層級、產品類別與統計數值，不一定需要把完整姓名、電話和門牌地址一起複製。Framework 在通知中表示，將重新評估分享給 BI 平台的資料廣度與深度，並把權限縮減到分析真正需要的欄位。這個補救方向合理，卻也反向證明事前的欄位配置可能過寬。

資安治理不能只靠「供應商承諾保密」。零時差漏洞的本質，就是即使使用最新版本、供應商也遵守既有流程，未知缺陷仍可能在修補前被利用。更有效的防線是資料最小化、權限最小化、短期保存、欄位去識別化，以及讓分析平台拿到的連線憑證只能讀必要的視圖，而不是整座資料庫。

對消費者而言，這次外洩的 metadata 也比「沒有密碼」看起來更棘手。密碼可以改、信用卡可以停用，但姓名、住址、電話與過去購買意圖很難更換；這些資料會長期提高釣魚、假客服、SIM swap 前置偵察與實體配送詐騙的可信度。

🚨 數據解讀與質疑：CVSS 10 不等於每座資料庫都已被搬空

需要把「漏洞最嚴重程度」與「Framework 已確認的實際影響」分開閱讀。CVSS 10.0 說明漏洞在最壞條件下可造成高度機密性、完整性與可用性衝擊；它不代表每一個 Metabase instance 都遭攻擊，也不證明攻擊者已讀取每一座相連的資料倉儲。

Framework 已確認的是其 Metabase instance 遭存取，以及特定客戶欄位出現在攻擊者讀取範圍。Framework 同時表示，當時未發現管理員帳號被更改，亦未發現 Metabase 外部系統遭存取。這些是有價值的初步邊界，但調查仍在進行，不能提早解讀成最終無擴大影響。

「有限資料外洩」這個措辭同樣值得質疑。若衡量標準是沒有密碼、卡號或社會安全號碼，確實比金融憑證外洩有限；但若衡量的是可識別個資種類，完整姓名、email、電話、登入 IP 與住址已形成相當完整的人物輪廓。事件規模又尚未公布受影響人數，因此目前無法用人數判定整體嚴重度。

最後，官方公告版本範圍的寫法存在小差異：Metabase 部落格以「1.58 以上」概述，GitHub advisory 則逐一列出 58 至 63 各分支的受影響與安全版本。實務上應以 GitHub 公告列出的修補版本為準，且截至發稿時 GHSA 尚無 CVE，不應把 2026 年其他 Metabase 漏洞的 CVE 編號誤套到本案。

自行架設 Metabase 的立即處置清單

官方建議 58 至 63 分支使用者更新到對應的最低安全版本：0.58.24、0.59.21、0.60.17、0.61.11、0.62.9 或 0.63.5。Enterprise 版本也有相對應的 1.x 修補版。若暫時無法升級，應先在反向代理或 WAF 封鎖 /api/session/reset_password，但這只能當短期緩解措施。

更新後仍需完成以下事件應變，而不是只重啟服務：

1. 清除 core_session 中的既有 session，迫使所有使用者重新登入。
2. 檢查並刪除不認識的 API keys 與管理員帳號。
3. 輪替每一組連線資料庫憑證，並確認權限是否超出分析所需。
4. 查核資料倉儲、Metabase activity 與 query history 是否出現異常查詢或大量匯出。
5. 搜尋攻擊特徵：POST /api/session/reset_password 回傳 400 後，緊接 GET /api/user/current 回傳 200。
6. 盤點 BI 平台內真正需要的欄位，移除姓名、電話、完整地址等不必要 PII。

若日誌出現上述兩個請求的連續樣式，Metabase 官方判斷該 instance 很可能已遭入侵，應依資安事件而非一般更新處理，保留日誌與快照、啟動鑑識，並評估法規通知義務。

社群反應：肯定快報，也要求資料最小化

Framework Community 與 Hacker News 的討論大致形成兩條主線。第一條肯定應變速度：Metabase 從 8 月 3 日發現事件到 8 月 6 日通知客戶，Framework 又在收到告警後約六小時通知受影響者，遠快於不少拖延數週或數月的外洩案例。

第二條則認為「透明」不能成為資料治理的免責牌。Framework Community 獲得較多按讚的留言，集中質疑第三方分析平台為何握有完整 PII，以及公司是否會對所有 SaaS 與資料處理流程進行全面稽核，而不只是縮減 Metabase 權限。Hacker News 使用者則把焦點放在難以更換的 metadata，以及未完成購買也可能被長期保存的問題。

這兩種評價並不矛盾：Framework 可以同時是「通知速度值得肯定」與「事前資料最小化不足」。真正能驗證改善的，不是再一封道歉信，而是後續是否公布受影響人數、完成第三方鑑識、縮小 BI 欄位、建立保存期限，並讓客戶能實際刪除不再必要的資料。

編按：截至 2026 年 8 月 7 日，Metabase 已確認主動利用並發布修補，但 Framework 與第三方鑑識仍在調查事件完整範圍。本文不把初步結果寫成最終結論，後續若官方更新受影響人數或資料範圍，應以新公告為準。