MariaDB 官方於 2026 年釋出 Galera Cluster 的緊急修補，對應三個高風險漏洞：CVE-2026-49261（CVSS 10.0，滿分）、CVE-2026-48165 與 CVE-2026-48163（皆 CVSS 8.0）。一句話震撼點：跑 MariaDB 多主同步叢集（Galera）的資料庫，可能被攻擊者透過 wsrep SST（State Snapshot Transfer）與 wsrep_notify_cmd 的不安全參數處理，在資料庫主機上執行任意系統指令——這不是資料外洩級，是整台 DB 主機被接管級。第一手來源為 MariaDB.org 的 Corrective Releases 公告與 MariaDB 官方 CVE 文件。
要理解技術原理，得先知道 Galera 是什麼。Galera 讓多台 MariaDB 同步成一個多主叢集，新節點加入時要透過 SST 把整份資料從現有節點（donor）搬到新節點（joiner）；這個搬運由外部腳本（wsrep_sst_method，如 mariabackup / rsync）執行，並透過 wsrep_notify_cmd 在叢集狀態變化時呼叫通知腳本。問題就出在這裡：donor 與 joiner 兩側對 SST 參數、以及 wsrep_notify_cmd 參數的處理不安全，能被注入並夾帶任意指令——攻擊鏈是污染 wsrep 參數 → SST/notify 腳本以資料庫服務權限執行 → 命令注入 → 拿下主機。CVSS 10.0 代表攻擊複雜度低、影響面全滿。
受影響範圍：使用 Galera Cluster 的 MariaDB Community Server。修補版本為 10.6.27、10.11.18、11.4.12、11.8.8，對應釋出日約 2026-05-27 起，並在 6 月初由 SUSE 等發行版持續推送安全更新。任何為了高可用而上 Galera 的中小企業正式環境，都在風險清單上。為什麼這值得 24 小時內動手？因為 CVSS 10.0 + 命令注入 + 資料庫權限，意味著一旦被打穿，攻擊者拿到的不只是資料，是整台主機的控制權。
技術細節（漏洞類型 + 攻擊路徑）
這組漏洞的核心是 OS Command Injection（作業系統命令注入），發生在 Galera 的 wsrep 機制：
- CVE-2026-49261（CVSS 10.0）：wsrep SST 在 donor／joiner 兩側對參數處理不安全。
- CVE-2026-48165 / CVE-2026-48163（CVSS 8.0）：
wsrep_notify_cmd等參數的不安全使用。
攻擊前置條件視部署而定：能影響 wsrep 設定、SST 流程、或叢集成員通訊的位置即可觸發。一旦注入成功，腳本以資料庫服務帳號權限執行系統指令。檢查你是否啟用 Galera：
-- 1) 確認是否在跑 Galera 叢集
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW VARIABLES LIKE 'wsrep_provider';
-- 2) 檢查目前版本是否低於修補版
SELECT VERSION(); -- 低於 10.6.27 / 10.11.18 / 11.4.12 / 11.8.8 即需升級三類讀者的立刻行動
- 系統管理員：立即把 MariaDB 升到 10.6.27 / 10.11.18 / 11.4.12 / 11.8.8 或更新；無法立即升級時，限制 Galera 埠（4567/4568/4444）僅在私有網段，並稽核 wsrep 設定來源是否可被非授權者修改。
- 開發者（含 Laravel/Nginx 環境）：即使是單機 MySQL，也該確認 production DB 不是別人順手開了 Galera；檢查部署腳本是否把 DB 管理埠暴露在公網。把資料庫主機與應用主機之間的網路分段。
- 接案商／顧問：對所有交付過高可用 MariaDB / Galera 架構的客戶，發出一封通告，主動報出受影響版本、修補版本、緩解步驟與你能提供的升級協助。低成本、高信任的客戶看護動作。
補丁 vs 緩解措施對照
- 立即補丁（首選）：升級到 10.6.27 / 10.11.18 / 11.4.12 / 11.8.8 或更新版本，採滾動升級避免停機。
- 緩解：用防火牆限制 Galera 埠 4567/4568/4444 僅限叢集內部私網；鎖定設定檔權限（僅 root 可寫）；確認
wsrep_notify_cmd、wsrep_sst_method不指向可被竄改的腳本；監控非預期子行程。
IOC 與威脅情資
- 異常行程樹：
mysqld/mariadbd衍生出rsync/mariabackup之外的非預期子行程（curl、wget、nc、外送 shell）。 - 設定竄改跡象：
wsrep_notify_cmd、wsrep_sst_method指向/tmp或含 shell metacharacter（;、|、$()、反引號）的值。 - 網路指標：Galera 埠 4444/4567/4568 出現來自非叢集成員 IP 的連線；資料庫主機對外非預期外連。
- 稽核重點：比對
my.cnf與部署 repo，找不在變更紀錄內的修改。
不會告訴你的事
- 很多 Galera 是被 HA 套件或雲廠商預設裝好的，使用者根本不知道自己在跑 Galera——這類影子叢集最危險，因為沒人在管它的版本。
- 滾動升級不是按一下就好。版本不一致時 wsrep 協定可能拒絕節點加入，升級本身有停機與資料一致性風險，得有演練。攻擊組織下一步很可能掃描公網上暴露 4567 埠的 Galera 節點。
這代表的更大趨勢
資料庫不再只是存資料的地方，而是被當成攻擊面的執行環境——透過備份、複寫、叢集同步這些運維機制打進主機，是 2025–2026 一條清楚的攻擊產業化路線（Magento、Mirasvit 快取、Galera SST 都是同一邏輯）。運維腳本的輸入驗證，正在變成 SecOps 必查項。
我的觀點
主流建議是列入 patch 清單、排進下次維護窗口。我的判斷不同：對 CVSS 10.0 的命令注入，下次維護窗口這個概念本身就該退役。但我也要說一句不討喜的：對中小企業，真正的風險不是沒升級，而是根本不知道自己在跑 Galera。對 ScriptWalker 的客戶看護機會很明確：把這次當成一次資料庫架構健檢的服務切入點——主動幫客戶盤點他們的 DB 是不是叢集、版本多舊、管理埠有沒有暴露，做一份兩頁的健檢報告。這正是你用一次資安事件，把一次性客戶轉成長期維運客戶的時機。