この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
先に一番大事な切り分けを置きます。今回の脆弱性が刺さるのは Galera Cluster（wsrep レプリケーション）を使っている構成だけです。1台で動かしているスタンドアロンのMariaDB、つまり
wsrep_on が無効なデフォルト構成は、MariaDB公式の修正リリース告知でも影響対象として挙がっていません。ここを最初に確認しないと、影響のないサーバーまで慌てて停めて余計な障害を作ります。もう一点、時系列も正直に書きます。話題化したのは2026年6月ですが、修正版（MariaDB Community Server）は2026年5月27日にすでに公開済みです。「6月に急に出た新しい穴」ではなく、「5月末に修正版が出ていたものが6月に広く流通した」という流れです。慌てる必要はありませんが、Galera構成なら確実に上げ切る、というのが今回の本筋です。
20年以上Linuxサーバーの現場にいますが、Galeraクラスタは「全停止せずに1台ずつ上げる」というローリングアップグレードの段取りが命です。本記事では、自分の構成が該当するかの判定から、系列別の上げ先、停止しない更新順序、wsrep関連の設定緩和までを通しでまとめます。
この記事のポイント
- 影響範囲は Galera Cluster（wsrep）構成に限定。スタンドアロン（
wsrep_on=OFF）のMariaDBは今回の対象外、と公式が明記。 - 修正版は 11.8.8 / 11.4.12 / 10.11.18 / 10.6.27（いずれも該当版以降）。2026年5月27日公開。話題化は6月だが修正版は5月末に出ている。
- 主軸は CVE-2026-49261（
wsrep_notify_cmdのパラメータインジェクション、CVSS 10.0）。ほか CVE-2026-48165 / 48163（SST joiner/donor 側、各CVSS 8.0）。 - Galeraは全停止せず 1ノードずつ離脱→更新→再JOIN のローリングで上げる。
wsrep_cluster_sizeを都度確認。 - 緩和として Galera通信ポート（4567 / 4568 / 4444）の外部遮断と
wsrep_notify_cmdスクリプトの権限・入力検証を点検。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
何が起きたのか — wsrep経由のコマンドインジェクション
3件のwsrep関連脆弱性がまとめて修正された
今回まとめて修正されたのは、Galeraクラスタのレプリケーション層（wsrep）に関わる複数の脆弱性です。MariaDB公式の11.8.8リリースノートなどで内容が明確に確認できるのは次の3件です。| CVE番号 | 箇所 | CVSS |
|---|---|---|
| CVE-2026-49261 | wsrep_notify_cmd のパラメータインジェクション |
10.0 |
| CVE-2026-48165 | SST joiner側（wsrep_sst_rsync）の安全でない値処理 |
8.0 |
| CVE-2026-48163 | SST donor側（wsrep_sst_donor / wsrep_sst_receive_address）の安全でない処理 |
8.0 |
最も重いCVE-2026-49261は、クラスタの他ノード（peer）から供給される
wsrep_node_name や wsrep_node_incoming_address といったノード識別子を検証せずに、通知コマンド行へそのまま差し込んでしまうというものです。Galeraはノードの参加・離脱などのイベント時に wsrep_notify_cmd で指定した外部スクリプトを呼びますが、その引数に他ノード由来の文字列が無検証で渡るため、悪意あるノード識別子を仕込まれるとコマンドインジェクションが成立し得ます。公式リリースノート上のCVSSは10.0（最大値）です。CVE-2026-48165 / 48163は、State Snapshot Transfer（SST、新規参加ノードへデータ一式を転送する仕組み）の joiner 側・donor 側で、
wsrep_sst_receive_address や wsrep_sst_donor といった実行時変更可能なシステム変数が、シェルコマンド構築時に適切にサニタイズされない、という系統です。いずれもwsrepに固有で、CVSSは各8.0です。なお素材として併記されていた別のCVE番号もありますが、本記事では内容とCVSSを一次情報で確実に確認できた上記3件に絞って解説します。確認の取れない番号を羅列して不安だけ煽ることはしません。
「Galera使っていなければ影響なし」を最初に確定させる
繰り返しになりますが、これらはすべてwsrep（Galera）由来の処理です。MariaDB.orgの告知も「If you are a Galera user（Galera利用者なら）」と明確に対象を限定し、Galera利用者にのみ即時アップグレードを推奨しています。つまり、1台構成のWordPress用DBや、レプリケーションを組んでいない小規模サーバーの多くは今回の直接の対象外です。とはいえ「自分はGaleraを使っていないはず」という思い込みで判定を飛ばすのは危険なので、次章でコマンドで実測します。
自分の構成がGalera（wsrep）か、まず実測する
wsrep_on と wsrep_provider を見る
該当判定の本質は、wsrepが有効でGaleraプロバイダがロードされているかの1点です。MariaDBにログインして次を確認します。-- wsrep が有効か（ON ならGalera構成） SHOW VARIABLES LIKE 'wsrep_on'; -- Galeraプロバイダ（libgalera_smm.so）が読まれているか SHOW VARIABLES LIKE 'wsrep_provider'; -- 現在のクラスタ台数（1なら単独 / 0なら未構成） SHOW STATUS LIKE 'wsrep_cluster_size'; -- 通知コマンドが設定されているか（49261の入口） SHOW VARIABLES LIKE 'wsrep_notify_cmd';
wsrep_on が OFF、または wsrep_provider が none なら、今回の脆弱性の直接の対象ではありません。wsrep_on が ON で wsrep_provider が /usr/lib/.../libgalera_smm.so を指しているなら、Galera構成として対応対象です。wsrep_cluster_size が2以上なら稼働中の本番クラスタなので、後述のローリング手順が必須になります。現行バージョンを確認する
該当判定と並行して、今動いているバージョンを系列まで把握します。系列（10.6 / 10.11 / 11.4 / 11.8）によって上げ先が変わるためです。# クライアントとサーバの版数 $ mysql --version $ mysql -e "SELECT VERSION();" # RHEL/AlmaLinux/Rocky系 $ rpm -q MariaDB-server galera-4 $ rpm -q mariadb-server # ディストリ同梱パッケージ名の場合 # Ubuntu/Debian系 $ dpkg -l | grep -E 'mariadb-server|galera'
galera-4 や galera パッケージが入っていれば、まずGalera構成と見て間違いありません。ディストリ同梱版（RHEL/Alma同梱）とMariaDB公式リポジトリ版で版数が異なる点に注意します。同梱版はディストリ側のバックポートで修正が当たることがあるため、版数の見た目が公式リリースノートと違っても、後述のCVE確認で修正済みかを判定します。
対象バージョン別の上げ先一覧
系列ごとに「同系列の修正版」へ上げる
今回の修正は、各メジャー系列の中で当たっています。系列をまたぐ大型アップグレード（例: 10.6→11.8）は不要で、同系列の修正版に上げれば塞がります。| 現行系列 | 上げ先（修正版） | 位置づけ |
|---|---|---|
| 10.6 系 | 10.6.27 以降 | LTS（長期サポート） |
| 10.11 系 | 10.11.18 以降 | LTS |
| 11.4 系 | 11.4.12 以降 | LTS |
| 11.8 系 | 11.8.8 以降 | 最新安定（GA） |
いずれも2026年5月27日公開です。たとえば10.11系のクラスタを運用しているなら、上げ先は10.11.18で、11.x系へ乗り換える必要はありません。系列内のマイナーアップグレードなので、ローリングで安全に当てられる範囲です。
修正が当たっているかをCVEで確認する
ディストリ同梱版を使っている場合は、版数の数字だけでなく、パッケージのchangelogでCVE番号が当たっているかを直接見に行くのが確実です。# RHEL/AlmaLinux/Rocky系: 更新情報からCVEを引く $ sudo dnf updateinfo list --cves CVE-2026-49261 $ sudo dnf check-update 'MariaDB-*' galera-4 # Ubuntu/Debian系: changelog でCVEをgrep $ apt changelog mariadb-server | grep -E "CVE-2026-49261|CVE-2026-48165|CVE-2026-48163" $ apt-get -s install mariadb-server # 取得予定版数の確認（シミュレート）
dnf repolist / apt policy mariadb-server で先に確認しておきます。PR / DB設計と運用の土台を押さえ直したい方へ
達人に学ぶDB設計徹底指南書 第2版 ミック / 翔泳社
MariaDB/MySQL系のデータベースを「どう設計し、どう運用に乗せるか」を腰を据えて押さえ直すのに向く一冊。レプリケーションやクラスタ構成の判断軸を持っておくと、wsrep固有の設定がどこに効くのかが見通しよくなります。
Galeraクラスタを止めずに上げるローリングアップグレード手順
1ノードずつ離脱→更新→再JOINが基本
Galeraの強みは、クラスタを全停止せずに1台ずつ更新できることです。同系列のマイナーアップグレード（例: 10.11.x→10.11.18）なら、ローリングアップグレードで無停止に近い形で当てられます。順序を崩すとクラスタが分断（split-brain）したりSST失敗で台数が欠けたりするので、段取りを守ります。基本の流れは「donor（最初の起動ノード）以外のノードから1台ずつ」です。
# 【各ノードで1台ずつ繰り返す。最後にdonor/起動ノードを更新】 # 1. 作業前にクラスタ台数を控える（例: 3 なら最後まで監視） $ mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';" # 2. 対象ノードのMariaDBを停止（このノードがクラスタから離脱） $ sudo systemctl stop mariadb # 3. 残りノードで台数が1減ったことを確認（例: 3 → 2） $ mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';" # 4. 離脱中のノードでパッケージを更新 # RHEL/Alma/Rocky系 $ sudo dnf update 'MariaDB-server' galera-4 # Ubuntu/Debian系 $ sudo apt update && sudo apt install --only-upgrade mariadb-server galera-4 # 5. 更新したノードを起動（IST/SSTで再JOIN） $ sudo systemctl start mariadb # 6. このノードが Synced になり、台数が戻ったことを確認（例: 2 → 3） $ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_comment';" # Synced を確認 $ mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
wsrep_local_state_comment が Synced に戻り、wsrep_cluster_size が元の台数に復帰してから、次のノードへ進みます。1台が再JOINで Synced になる前に次のノードを落とすと、台数が一気に減ってクォーラムを失うことがあるため、ここは焦らず1台ずつです。最後に起動ノードを更新し、SSTを避ける
最初に起動した（bootstrapした）ノードは最後に回します。先に落とすと、残りノードの再選出や大きなSSTが走りやすく、ダウンタイムが伸びます。再JOIN時に IST（差分転送）で済めば短時間、SST（フル転送）になるとデータ量次第で長時間かかるため、停止時間を最小化するには「短時間で離脱・更新・復帰」を1台ずつ淡々と回すのが要点です。全ノードの更新が終わったら、各ノードの版数が揃ったことを確認します。
# 全ノードでバージョンとクラスタ状態がそろっているか $ mysql -e "SELECT VERSION();" $ mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';" # 全ノードで同じ台数 $ mysql -e "SHOW STATUS LIKE 'wsrep_cluster_status';" # Primary であること
wsrep_notify_cmd とSST周りの設定を緩和する
更新が即座にできない場合の緩和策
クラスタの更新窓がすぐ取れない場合の暫定緩和です。根本対処はあくまでバージョン更新ですが、攻撃の入口を狭める意味で有効です。第一はネットワークです。Galera通信ポート（4567 / 4568 / 4444）を信頼できるノード間だけに限定し、外部・不要セグメントから遮断します。今回の脆弱性は「他ノードから供給される値」を起点にするため、信頼できないノードがクラスタ通信に到達できないようにするのが効きます。
# Galera関連ポートをクラスタ内ノードのIPに限定（firewalld例） # 4567=レプリケーション / 4568=IST / 4444=SST $ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \ source address="10.0.0.0/24" port port="4567" protocol="tcp" accept' $ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \ source address="10.0.0.0/24" port port="4568" protocol="tcp" accept' $ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" \ source address="10.0.0.0/24" port port="4444" protocol="tcp" accept' $ sudo firewall-cmd --reload # 現在の待ち受け確認 $ ss -ltnp | grep -E ':4567|:4568|:4444'
通知スクリプトの権限と入力検証
wsrep_notify_cmd を使っている場合は、呼び出されるスクリプトを点検します。スクリプトの所有者・パーミッションを絞り、引数として渡されるノード識別子をそのままシェルに流さない（変数を必ずクォートし、想定外の文字を弾く）よう見直します。# 通知コマンドの設定とスクリプト権限を確認 $ mysql -e "SHOW VARIABLES LIKE 'wsrep_notify_cmd';" $ ls -l /path/to/wsrep_notify.sh # 所有者 mysql、書込みは最小限に # SST関連の実行時変数も確認（48163/48165の入口） $ mysql -e "SHOW VARIABLES LIKE 'wsrep_sst_method';" $ mysql -e "SHOW VARIABLES LIKE 'wsrep_sst_donor';" $ mysql -e "SHOW VARIABLES LIKE 'wsrep_sst_receive_address';"
wsrep_sst_method）に rsync を使っている場合は48165が直接関わるため、更新優先度を上げます。mariabackup など他方式でも、実行時変数のサニタイズ不足という構図は共通なので、緩和より更新を優先する判断は変わりません。
更新後の検証と今日のチェックリスト
版数・クラスタ整合・修正済みの3点を実測する
更新後は、見た目だけでなく実測で締めます。全ノードで版数が揃い、クラスタがPrimaryで台数が一致し、CVEが修正済みであること、の3点です。# 1. 全ノードで版数一致 $ for h in node1 node2 node3; do ssh $h "mysql -e 'SELECT VERSION();'"; done # 2. クラスタが Primary・台数一致・全ノード Synced $ mysql -e "SHOW STATUS LIKE 'wsrep_cluster_status';" $ mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size';" $ mysql -e "SHOW STATUS LIKE 'wsrep_local_state_comment';" # 3. 修正が当たっているか（ディストリ同梱版） $ sudo dnf updateinfo list --cves CVE-2026-49261 # 残っていなければOK（RHEL系） $ apt changelog mariadb-server | grep CVE-2026-49261 # 出ればOK（Ubuntu系）
- Galera構成かを実測:
SHOW VARIABLES LIKE 'wsrep_on';とwsrep_providerを確認。OFF/none なら今回は対象外と確定。 - 現行系列を把握:
SELECT VERSION();とrpm -q/dpkg -lで系列（10.6 / 10.11 / 11.4 / 11.8）を確定。 - 同系列の修正版へ上げる: 10.6.27 / 10.11.18 / 11.4.12 / 11.8.8 以降。系列はまたがない。
- ローリングで1台ずつ: 離脱→更新→再JOIN→Synced確認を繰り返し、起動ノードは最後に。台数復帰を毎回確認。
- 緩和を併用: ポート4567/4568/4444をクラスタ内に限定。
wsrep_notify_cmdスクリプトの権限・入力検証を点検。 - 更新後に実測: 全ノード版数一致・Primary・台数一致・CVE修正済みの3点を確認して締める。
教訓 — 「スタンドアロンか、Galeraか」で初動が変わる
今回いちばん効いたのは、技術的な手順そのものより「自分の構成が該当するかを最初に1コマンドで確定させる」という切り分けでした。CVSS 10.0という数字だけが独り歩きすると、影響のないスタンドアロンDBまで巻き込んで不要な障害を作りがちです。逆にGalera構成なら、慌てて全停止するのではなく、ローリングで1台ずつ淡々と上げ切るのが正解です。修正版は5月末に出ていて、当てる手順も確立しています。「最大級のCVSSだから今すぐ全部落とす」ではなく、「該当するなら正しい順序で確実に上げる」。この差が、現場での被害と無停止運用の分かれ目になります。
PR / あわせて読みたい本
- Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本 中島 能和 / 翔泳社
- 達人に学ぶDB設計徹底指南書 第2版 ミック / 翔泳社
「サーバ側で何を守るか」と「DBをどう設計・運用するか」を両輪で押さえる2冊。Galeraのwsrep設定を点検する際の判断軸として効きます。
- MariaDB.org 修正リリース告知（Galera）: https://mariadb.org/mariadb-community-server-corrective-releases/
- MariaDB 11.8.8 リリースノート: https://mariadb.com/docs/release-notes/community-server/11.8/11.8.8
- MariaDB 11.4.12 リリースノート: https://mariadb.com/docs/release-notes/community-server/11.4/11.4.12
- MariaDB 10.11.18 リリースノート: https://mariadb.com/docs/release-notes/community-server/10.11/10.11.18
- MariaDB 10.6.27 リリースノート: https://mariadb.com/docs/release-notes/community-server/10.6/10.6.27
- MariaDB Community Server 修正済みCVE一覧: https://mariadb.com/docs/server/security/cve/community-server
- Amazon Linux CVE-2026-49261: https://explore.alas.aws.amazon.com/CVE-2026-49261.html
Galeraのローリングアップグレード、自信を持って回せていますか？
wsrep_on の確認、wsrep_cluster_size の監視、1台ずつの離脱と再JOIN、Synced の見極め。Galeraクラスタの無停止更新は、読むだけでなく実機で繰り返して初めて手が動くようになります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます