MariaDB Galera RCE脆弱性 CVE-2026-49261（CVSS 10.0）｜影響確認とパッチ手順

2026年6月、世界的に使われるオープンソースのリレーショナルデータベースMariaDBに、最大深刻度CVSS 10.0のリモートコード実行（RCE）脆弱性CVE-2026-49261が公表された。原因はMariaDBのクラスタ機能Galera Clusterを支えるwsrep（write-set replication）まわりにあり、外部由来の値が検証されないままコマンド行へ展開されるパラメータインジェクションだ。同時に公表されたCVE-2026-48165・CVE-2026-48163（いずれもCVSS 8.0）も同系統の問題で、いずれもmariadbdプロセス権限でのコマンド実行に至り得る。本記事では、自組織が影響を受けるかの確認・修正版へのパッチ適用・SCA（Software Composition Analysis）による継続検知までを、手順を軸に解説する。

データベースやインフラを含むAI時代のセキュリティ全体像を整理したい方は、ピラー記事AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイドを先に押さえると、本記事の位置づけがつかみやすい。

30秒で理解する

まず要点だけを押さえる。CVE-2026-49261は「MariaDBのGaleraレプリケーション（wsrep）が、クラスタ通信の相手から受け取った値を検証せずにコマンドとして実行してしまう」という構造に集約される。攻撃ペイロードの詳細は本記事では扱わず、影響確認・遮断・修正という防御側の動きに焦点を当てる。

・対象と深刻度: CVE-2026-49261（CVSS 10.0 / Critical）を筆頭に、CVE-2026-48165・CVE-2026-48163（各CVSS 8.0）の計3件。いずれもwsrep/Galera関連のパラメータインジェクション
・影響範囲: MariaDB 10.6 / 10.11 / 11.4 / 11.8系で、各修正版未満のビルド。攻撃面はGalera Cluster（wsrep_on=ON）を運用している環境
・修正版: 10.6.27 / 10.11.18 / 11.4.12 / 11.8.8。10.6.27は2026年5月27日リリース、公式（mariadb.org）の告知は6月2日
・確認手順: （1）SELECT VERSION()で実バージョン （2）パッケージ／イメージのバージョン （3）wsrep_onの有効状態 （4）クラスタ通信ポートの公開状況
・当面の対応: 修正版への更新が最優先。即時に上げられない場合はGaleraのクラスタ通信経路（4567/4568/4444）を外部から遮断し、信頼できないノードがクラスタに参加できない状態を作る

何が起きたか — MariaDB GaleraのRCE脆弱性

2026年5月27日にMariaDB 10.6.27がリリースされ、2026年6月2日に公式サイト（mariadb.org）のコミュニティサーバ修正リリース告知で、Galera Cluster利用者向けの高深刻度脆弱性として3件のCVEが公表された。CVE番号はCVE-2026-49261（CVSS 10.0）、CVE-2026-48165（CVSS 8.0）、CVE-2026-48163（CVSS 8.0）である。公式は「Galeraユーザーは至急アップデートを強く推奨する」と明記しており、対象系列（10.6 / 10.11 / 11.4 / 11.8）の修正版が同時に提供された。

MariaDBはMySQL互換のオープンソースRDBで、Galera Clusterはその同期マルチマスタレプリケーションを担う仕組みだ。ノード間のデータ同期にはwsrep APIが使われ、新規ノードがクラスタに参加する際は既存ノード（ドナー）から状態を丸ごと転送するSST（State Snapshot Transfer）が走る。今回の脆弱性群は、このSSTやノード状態変化を外部スクリプトへ通知するwsrep_notify_cmdといった、クラスタ通信の相手から値を受け取る経路に集中している。

データベース・ミドルウェア層を狙った高深刻度の脆弱性は、フレームワーク層と同様に後を絶たない。直近でも、テストランナーのサーバ化を突いたVitest RCE脆弱性（CVE-2026-47429ほか）の影響確認・パッチ適用・SCA検知の手順、SSRのデシリアライズを悪用するReact Router v7 RCE脆弱性（CVE-2026-42211）の解説、低特権認証からexecutor RCEに至るOpenStack Mistral RCE脆弱性（CVE-2026-41283 / CVSS 9.9）の確認と修正手順を公開してきた。今回のMariaDBも、これらと同じ「信頼境界の内側だと思われていた内部通信経路が、実は外部入力を処理していた」系統に位置づけられる。

なお本記事執筆時点で、NVD上のCVE-2026-49261はRESERVED状態であり、CVSSベクトル文字列やCWEの詳細はまだ公開されていない。確定している事実はMariaDB公式が示すCVSSスコア10.0という値で、攻撃ベクトルの正確な分解はNVD公開後に確定する。本記事では、公式の記述から確実に言える範囲を「事実」、そこから合理的に導かれる範囲を「推測」として区別して述べる。

脆弱性の詳細：wsrepのパラメータインジェクション

公式ドキュメント（mariadb.com/docs）と修正リリースの記述から、今回の3件はいずれもwsrep関連機能でのパラメータインジェクションであることが確定している。具体的には、次の3つのコンポーネントが挙げられている。

・wsrep_sst_rsync（ジョイナー側）: rsync方式のSSTで、ジョイナーが供給するWSREP_SST_OPT_REMOTE_USERの値を検証していなかった（MariaDB側の追跡課題: MDEV-39648）
・wsrep SST受信アドレス（ジョイナー側）: wsrep_sst_receive_address等の値の扱いが安全でなく、権限のある利用者がmariadbdプロセスのuidでシェルコマンドを実行し得た（MDEV-39676相当）
・wsrep_notify_cmd: ノード状態変化を通知するコマンドで、ピアが供給するwsrep_node_name・wsrep_node_incoming_addressを検証せず通知コマンド行へ展開していた（MDEV-39721相当）

これらに共通する構造は明快だ。Galera Clusterでは、SSTやノード通知のために外部（参加ノードやピア）から受け取った文字列を、シェルやrsyncのコマンド行に組み立てて実行する処理が存在する。その文字列に対するサニタイズ（エスケープ・検証）が欠けていると、攻撃者は値の中にコマンド区切りやオプションを紛れ込ませ、本来意図しないコマンドをmariadbdプロセスの権限で実行できてしまう。これが「パラメータインジェクション」の正体である。

攻撃の流れを俯瞰すると、(1) 攻撃者がクラスタ通信経路に到達し、(2) SSTのジョイナー値やノード通知の値として細工した文字列を供給し、(3) 検証を欠いたコマンド組み立てを通じて、(4) mariadbdプロセス権限で任意コマンドが実行される——という連鎖になる。下図はこの一連の流れを示したものだ（攻撃ペイロードの具体例は安全のため掲載しない）。

重要なのは、この脆弱性がGalera Cluster（wsrepを有効化した構成）に固有だという点だ。wsrepを使わない単体（スタンドアロン）のMariaDBは、SSTやwsrep_notify_cmdという経路自体を持たないため、今回のベクトルには直接さらされない。とはいえバージョン自体は脆弱なビルドであり、運用ポリシー上は修正版へ揃えるのが安全だ。

影響範囲：影響バージョンと修正バージョン

影響範囲を表に整理する。判定の軸は「MariaDBのバージョン」と「Galera（wsrep）の有効状態」の2つだ。

ここで現実的な落とし穴を一つ補足する。「うちはGaleraを使っていない」と思っていても、ディストリのパッケージにはwsrep providerが同梱されていることが多く、設定で無効化しているだけというケースがある。後述のSHOW VARIABLES LIKE 'wsrep_on'で実際の有効状態を確認することが、影響範囲判定の出発点になる。

⚡対応確認の手順（重点セクション）

ここからが本記事の中心だ。自組織が影響を受けるかを確実に判定し、対応漏れを防ぐための手順を4ステップで示す。下図は、この4ステップの判定フローを俯瞰したものだ。

Step 1: 自分の環境でMariaDBを使っているか・どこで動いているか

まず、どこでMariaDBが動いているかを棚卸しする。直接構築したものだけでなく、コンテナイメージやマネージドサービス経由のものも見逃さない。

# ホスト上のMariaDB/mariadbdプロセスを確認
ps aux | grep -E "mariadbd|mysqld" | grep -v grep

# systemd管理下のサービス
systemctl list-units --type=service | grep -iE "mariadb|mysql"

# 稼働中のコンテナでMariaDBイメージを使っているもの
docker ps --format '{{.Image}}\t{{.Names}}' | grep -i mariadb

# Kubernetes上のMariaDB Pod（全namespace横断）
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}' | grep -i mariadb

自宅サーバ・オンプレVM・ECS/EKS・GKE・各種コンテナと、MariaDBは様々な場所に潜む。特にGalera Clusterは複数ノードで構成されるため、全ノードを漏れなくリストアップすることが重要だ。

Step 2: バージョンを確定する

次に実際の稼働バージョンを確認する。SELECT VERSION()が最も確実だが、稼働中DBに接続できない場合はパッケージやイメージから確認する。

# 稼働中DBに接続して確認（最も確実）
mariadb -e "SELECT VERSION();"
mysql -e "SELECT VERSION();"   # mariadbクライアントがない環境

# パッケージから確認（Debian/Ubuntu系）
apt list --installed 2>/dev/null | grep -i mariadb
dpkg -l | grep -i mariadb-server

# パッケージから確認（RHEL/Rocky/Alma系）
yum list installed 2>/dev/null | grep -i mariadb
rpm -qa | grep -i mariadb

# コンテナイメージのタグとラベルを確認
docker image inspect mariadb:VERSION --format '{{.RepoTags}}\t{{index .Config.Labels "org.opencontainers.image.version"}}'

実バージョンが各系列の修正版未満（10.6系<10.6.27 / 10.11系<10.11.18 / 11.4系<11.4.12 / 11.8系<11.8.8）なら影響対象だ。コンテナではmariadb:10.11のような可変タグを使っていると、いつの間にか古いビルドに固定されていることがあるため、SELECT VERSION()での実値確認を優先する。

Step 3: Galera（wsrep）の有効状態とクラスタ通信ポートの公開状況

今回の攻撃面はGalera（wsrep）に固有なので、wsrepが有効かどうかが判定の核心になる。あわせて、クラスタ通信ポートの外部公開状況を確認する。

-- wsrepが有効か（OFFなら今回のSST/notify経路の攻撃面は持たない）
SHOW VARIABLES LIKE 'wsrep_on';

-- クラスタの構成・状態を確認
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_cluster_status';

-- SST方式とnotify_cmdの設定を確認
SHOW VARIABLES LIKE 'wsrep_sst_method';
SHOW VARIABLES LIKE 'wsrep_notify_cmd';

# Galeraのクラスタ通信ポートが外部公開されていないか
# 4567=group communication / 4568=IST / 4444=SST / 3306=SQL
ss -tlnp | grep -E ':(4567|4568|4444|3306)'

# AWS SecurityGroupで0.0.0.0/0に開いていないか（aws CLI）
aws ec2 describe-security-groups \
  --query "SecurityGroups[].IpPermissions[?contains([4567,4568,4444,3306], FromPort)]" \
  --output table

wsrep_onがONで、かつクラスタ通信ポートが広いネットワークに公開されている構成は最優先の対応対象だ。これらのポートはクラスタノード間でのみ到達できれば十分で、インターネットや広い社内ネットワークに開ける必要はない。

Step 4: ログ・監視の確認

最後に、影響バージョンを使っていた期間の運用ログを点検する。確実な侵害判定は難しいが、リスク評価には有効だ。

・SSTログ: rsync/mariabackup方式のSST実行ログに、想定外のコマンド・引数・リモートユーザー名が記録されていないか
・notify_cmdの実行履歴: wsrep_notify_cmdに指定したスクリプトのログに、見覚えのないノード名・アドレスや子プロセス生成がないか
・プロセス／システムログ: mariadbdのuidで実行された不審なシェルコマンド・外部通信・ファイル書き込みを、auditd・EDR・APMで横断確認
・クラスタメンバーシップ: 見覚えのないIPからのノード参加（join）やSSTドナー要求が、Galeraのメンバーシップ変更ログに残っていないか

⚙️ 修正手順

確認が済んだら修正に進む。運用形態に応じて3つのパターンを示す。Galera Clusterはローリングで更新できるのが利点だ。

A. シンプルなアップデート（パッケージ管理のサーバ）

最も基本的なのは、パッケージマネージャでMariaDB serverを修正版へ更新することだ。

# Debian/Ubuntu系
sudo apt update
sudo apt install --only-upgrade mariadb-server mariadb-client
mariadb -e "SELECT VERSION();"   # 修正版になったか確認

# RHEL/Rocky/Alma系
sudo dnf upgrade mariadb-server mariadb
mariadb -e "SELECT VERSION();"

単体構成なら、更新後にサービスを再起動しSELECT VERSION()で修正版になっていることを確認すれば完了だ。Galera Clusterの場合は、次のBのローリング手順に従う。

B. Galera Clusterのローリングアップグレード

クラスタ全体を止めずに更新するには、ノードを1台ずつ外して更新し、再参加させる。全ノードのバージョンが揃うまで攻撃面が残るため、最後のノードまで上げきることが重要だ。

# --- 各ノードで1台ずつ実行 ---
# 1) このノードをクラスタから安全に外す
sudo systemctl stop mariadb

# 2) パッケージを修正版に更新
sudo apt install --only-upgrade mariadb-server mariadb-client   # Debian系
# sudo dnf upgrade mariadb-server mariadb                        # RHEL系

# 3) クラスタに再参加（既存ノードへIST/SSTで同期）
sudo systemctl start mariadb

# 4) このノードが同期済みになったか確認してから次のノードへ
mariadb -e "SHOW STATUS LIKE 'wsrep_local_state_comment';"   # 'Synced' を確認
mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_size';"          # ノード数が戻ったか

wsrep_local_state_commentがSynced、wsrep_cluster_sizeが想定ノード数に戻ったことを確認してから次のノードへ進む。更新中の混在期間は、後述の暫定策（クラスタ通信ポートの外部遮断）を必ず維持する。

C. Docker/Kubernetes環境での更新

コンテナ環境では、イメージタグを修正版に固定して再デプロイする。可変タグ（mariadb:10.11等）のままだと再現性がないため、修正版を含む明示タグへ更新する。

# Docker Compose: イメージタグを修正版に固定して再作成
# (compose.yamlのimage: mariadb:10.11.18 等に書き換えてから)
docker compose pull
docker compose up -d
docker compose exec db mariadb -e "SELECT VERSION();"

# Kubernetes（StatefulSetのイメージを修正版に更新する例）
# kubectl set image でローリング更新
#   kubectl set image statefulset/mariadb-galera \
#     mariadb=mariadb:10.11.18 -n db
spec:
  template:
    spec:
      containers:
        - name: mariadb
          image: mariadb:10.11.18   # 修正版の明示タグに更新

StatefulSetのローリング更新では、Pod順次再作成のたびにSST/ISTが走る。更新中もクラスタ通信用のServiceは内部限定（ClusterIP / NetworkPolicyで制限）にしておき、外部に露出させないことが前提だ。

暫定策：すぐに更新できない場合

事情があって即時更新できない場合の緩和策を挙げる。いずれも時間稼ぎであり根本対策ではない。

・クラスタ通信ポートの外部遮断: 4567/4568/4444（および必要に応じ3306）を、SecurityGroup・iptables・nftablesでノードのIPだけに絞る。これが最優先
・参加ノードの制限: クラスタへjoinできるノードを認証・ネットワークで制限し、信頼できないノードがSSTのドナー／ジョイナーになれない状態にする
・notify_cmdの見直し: wsrep_notify_cmdを使っている場合、スクリプト側で受け取る値を厳格に検証・エスケープする（更新までの緩和）
・公開範囲の縮小: そもそもDBノードを外部到達可能な場所に置いていないか、ネットワーク設計を見直す

SCA／脆弱性管理での継続検知

今回のように「広く使われるミドルウェアのバージョン起因」の脆弱性は、人手の棚卸しだけでは追い切れない。コンテナイメージやサーバ構成に対してSCA／脆弱性スキャナを定期実行し、新たなアドバイザリが出た瞬間に気づける状態を作るのが本質的な対策だ。

最短ルートはTrivyだ。コンテナイメージや稼働ホストに対して一発でMariaDBのバージョンとCVEを突き合わせられる。CIに組み込む最小例は次のとおりだ。

# .github/workflows/sca.yml（抜粋）
name: SCA
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Trivy scan (MariaDBイメージのCVEを検知)
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'mariadb:10.11.18'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'   # CRITICAL/HIGHが出たらCIを失敗させる

severity: CRITICAL,HIGHとexit-code: 1を組み合わせれば、CVSS 10.0のCVE-2026-49261のようなCRITICALが混入した時点でCIを赤くできる。稼働中ホストにはtrivy rootfs /やtrivy fsを、SBOM運用にはGrypeを重ねると、ビルド時と運用時の両面で検知できる。

過去の類似事案：DBミドルウェアとレプリケーションの系譜

MariaDBのケースは突発的な単発事故ではなく、DBミドルウェアが構造的に抱えるリスクの一例だ。近年の方向性を振り返ると、対策の勘所が見えてくる。

・レプリケーション／クラスタ経路の信頼前提: クラスタ内通信は「信頼できる相手」と暗黙に前提しがちで、SSTやノード通知のような外部値を扱う処理にサニタイズ漏れが残りやすい。今回のwsrepはその典型だ
・外部コマンド呼び出しのインジェクション: DBが外部スクリプト・rsync・バックアップツールを呼ぶ箇所は、引数組み立てのエスケープ漏れがコマンドインジェクションに直結する。CWE-78系として繰り返し悪用される
・サプライチェーン文脈での波及: 攻撃者が正規パッケージを汚染する事例も増えており、OpenAI Codexを狙うnpmサプライチェーン攻撃（codexui-android偽パッケージ）の検知と対応のように、依存や周辺ツールから侵入される経路にも注意が要る
・EOL系列の放置: 修正版が提供されない古い系列を使い続けると、パッチが出ずリスクだけが残る。サポート系列への移行が前提になる

これらに共通するのは「信頼境界の内側だと思っていた場所が、実は外部入力に晒されていた」という構図だ。AI時代の脅威モデル全体の中での位置づけは、ピラー記事AIセキュリティとは？で体系的に整理している。

企業向け対応チェックリスト

組織として今回の脆弱性に対応する際のチェックリストをまとめる。

よくある落とし穴

現場で起きがちな失敗をまとめる。

・「Galera未使用」の思い込み: パッケージにwsrep providerが同梱され、設定で無効化しているだけのケースがある。SHOW VARIABLES LIKE 'wsrep_on'で実状態を必ず確認する
・一部ノードの更新漏れ: ローリング更新の途中で1台でも旧バージョンが残ると攻撃面が残る。wsrep_cluster_sizeと全ノードのSELECT VERSION()で揃ったことを確認する
・可変タグへの依存: mariadb:10.11のような可変タグは、いつの間にか古いビルドに固定される。修正版の明示タグへ更新し、SELECT VERSION()で実値を確認する
・ポート遮断の後回し: 「更新すれば直る」と考えてポート遮断を後回しにしがちだが、全ノード更新完了までの混在期間こそ危ない。先にクラスタ通信ポートを内部限定にする
・EOL系列の見落とし: 10.5以前など修正版が出ない系列を使い続けると、パッチ適用そのものができない。サポート系列への移行を計画する

まとめ

MariaDBのGalera Cluster（wsrep）に公表されたCVE-2026-49261（CVSS 10.0）は、SSTやwsrep_notify_cmdで外部由来の値が検証されずコマンド行へ展開される、典型的なパラメータインジェクション起因のRCEだ。同時公表のCVE-2026-48165・CVE-2026-48163（各8.0）も同系統で、いずれもmariadbdプロセス権限でのコマンド実行に至り得る。攻撃面はGalera（wsrep有効）構成に固有で、単体構成は直接の対象になりにくいが、バージョン自体は脆弱なため修正版へ揃えるのが安全だ。

対応はシンプルである。SELECT VERSION()とwsrep_onで影響有無を判定し、クラスタ通信ポートを外部遮断したうえで、修正版（10.6.27 / 10.11.18 / 11.4.12 / 11.8.8）へローリング更新する——この流れを押さえれば本脆弱性は確実に封じられる。あわせてTrivy等のSCAをCIと運用監視に組み込めば、同系統の将来の脆弱性にも素早く気づける体制になる。NVDの詳細解析を待つ必要はなく、MariaDB公式の修正リリースで影響範囲と修正版は確定している。今すぐSHOW VARIABLES LIKE 'wsrep_on'から始められる。

参照ソース

・MariaDB Community Server Corrective Releases（MariaDB.org 公式告知） — 一次ソース。Galera向け3件のCVE公表と修正版（10.6.27 / 10.11.18 / 11.4.12 / 11.8.8）、「Galeraユーザーは至急アップデートを」の記述
・MariaDB 10.6.27 Release Notes（MariaDB公式ドキュメント） — リリース日（2026-05-27）とCVE-2026-49261（CVSS 10.0）・CVE-2026-48165・CVE-2026-48163（各8.0）の対応
・Security Vulnerabilities (CVE) Fixed in MariaDB Community Server（MariaDB公式CVE一覧） — wsrep SST／wsrep_notify_cmdのパラメータインジェクションという技術的位置づけ
・CVE-2026-49261（NVD・National Vulnerability Database） — 本記事時点でRESERVED。CVSSベクトル等の確定はNVD公開後