MariaDBにサーバー乗っ取りの脆弱性、Galera利用者は更新を CVE-2026-49261

世界中のWebサービスの裏側で使われているデータベースMariaDB（マリアディービー）に、危険度が最高値の10.0と評価された深刻な脆弱性（CVE-2026-49261）が見つかり、修正版が公開されました。MariaDBは、会員情報や注文履歴などを保管する定番のデータベースソフトで、MySQLから派生した後継として、多くのレンタルサーバーや業務システムで動いています。今回の穴を突かれると、データベースのサーバーそのものが乗っ取られる恐れがあります。

ただし、ここが肝心です。この10.0の穴が刺さるのは、複数台のサーバーで同じデータを同期し合う「Galera（ガレラ）クラスタ」という構成を組み、さらにwsrep_notify_cmdという通知機能を有効にしている環境に限られます。1台だけで動かしている普通のMariaDB（多くのWordPressサイトや小規模システムはこちら）は、CVE-2026-49261の対象ではありません。まずは「うちはMariaDBを複数台でクラスタ運用しているか」を確認するのが出発点です。

該当する場合は緊急対応が必要です。MariaDB公式は2026年5月27日に修正版（10.6.27／10.11.18／11.4.12／11.8.8／12.3.2）を公開し、「Galeraを使っているなら、できるだけ早く更新することを強く推奨する」と呼びかけています。今のところ実際の攻撃に使われたという報告はありませんが、修正の公開後は穴の場所が把握されやすくなります。

Galeraクラスタとは何で、誰が対象なのか

Galeraクラスタは、複数台のMariaDBを束ねて「どの1台が落ちてもサービスを止めない」ようにする仕組みです。すべてのサーバーが同じデータをリアルタイムで持ち合い、お互いに同期し続けます。アクセスが多いWebサービスや、止められない業務システムの裏側で広く使われています。この「ノード（サーバー）同士が連絡を取り合う」部分の処理に、今回の穴がありました。

問題のwsrep_notify_cmdは、クラスタのメンバーが増減したときに、管理者が指定したスクリプトを自動で呼び出す通知機能です。便利な反面、新しく加わったノードの「名前」をそのままコマンドの一部に組み込んでしまうため、名前に細工をされると、そこに紛れ込ませた命令がサーバー上で実行されてしまいます。下の表で、自分の運用がどこに当てはまるかを確認してください。

つまり、MariaDBを使っているからといって全員が今すぐ慌てる必要はありません。一方で、Galeraで高可用性（落ちない仕組み）を組んでいるなら、これは「条件が揃えば」ではなく「該当する以上は緊急」の案件です。クラウドのマネージドなデータベースサービスを使っている場合は、提供元が対応するため、各社の告知を確認すれば十分です。

何が起きるのか — 最高スコア10.0の中身

今回まとめて直ったGalera関連の穴は3件です。いずれも「外から渡された値を、確認せずにそのままコマンドの材料にしてしまう」という同じ種類の不備（OSコマンドインジェクション）です。危険度の数字は、深刻さを0〜10で表す国際的な共通スコア「CVSS」です。

中でもCVE-2026-49261が10.0と最も重いのは、攻撃に特別な権限が要らず、成功すればデータベースを動かしている権限のまま任意のコマンドをサーバー上で実行できる（機密性・完全性・可用性のすべてに最大の被害が及ぶ）と評価されたためです。残る2件も、同じくGaleraの同期まわりで外部由来の値が安全に扱われていなかった不備で、いずれも修正版で塞がれています。

狙われると何が起きるのか

MariaDBは多くのWebサービスの裏で動く定番のデータベースで、会員情報や取引のすべてがここに集まります。最悪の穴を狙うのは、クラスタの通信網に手が届く位置まで侵入した攻撃者、内部ネットワークに足場を得たランサムウェア集団、Galeraのポートを外部に晒したサーバーを探すスキャン業者です。持ち去られるのは、会員情報・注文履歴・パスワードのハッシュ、そしてデータベースサーバーそのものの制御です。細工した名前のノードがクラスタに加わった瞬間、その名前が通知コマンドの一部としてシェルで実行され、DBを動かす権限のまま攻撃者の命令が走ります。

制御を握られれば、被害は1台で終わりません。全ノードに同じ通知が配られる作りのため、一台の乗っ取りがクラスタ全体へ広がります。抜き取られた会員データは闇市場で売られ、買い手がなりすましやフィッシングを仕掛け、ハッシュ化されたパスワードは破られて別サービスに使い回されます。さらにそのサーバーを足場に、社内の別サーバーへ侵入が広がります。

そして被害の責任は、MariaDBの開発元ではなく、そのクラスタを運用する会社に返ってきます。会員の個人情報が漏れれば個人情報保護委員会への報告と本人通知が義務づけられ、規模次第で損害賠償と信用失墜がのしかかります。CVSS 10.0という最高値は技術的な深刻さの目盛りにすぎず、現実のコストは事故後の対応にこそ表れます。Galeraを使っているなら、修正版へ上げるか通信を閉じるか、今その判断ができるかが分かれ目です。

それぞれの穴をくわしく見る

CVE-2026-49261: ノードの名前がコマンドとして実行される穴

Galeraクラスタでは、新しいサーバーが仲間に加わったり抜けたりするたびに、状態の変化を管理者へ知らせる通知の仕組みが用意されています。それがwsrep_notify_cmdで、ここに指定したスクリプトが自動で呼び出されます。問題は、加わってきたノードの名前（wsrep_node_name）や受信アドレス（wsrep_node_incoming_address）を、中身を確認しないまま通知コマンドの文字列に差し込んでいたことです。

コンピュータのコマンドは、特定の記号（セミコロンやバッククォートなど）を「ここから別の命令」と解釈します。そのため、ノードの名前に細工した記号と命令を仕込んでクラスタに参加させると、本来は単なる名前のはずの文字列が、サーバー上で動く新たな命令として実行されてしまいます。実行されるのはMariaDBの本体プロセス（mariadbd）の権限なので、データベースの中身を抜くのはもちろん、サーバーに別のプログラムを置く、他のサーバーへ攻撃を広げる、といったことまで可能になります。これが「OSコマンドインジェクション」と呼ばれる、外部の入力を命令としてすり込む典型的な攻撃です。CVSSは10.0、報告はGitHubのセキュリティ研究チームからとされています。

CVE-2026-48163 / CVE-2026-48165: 同期処理に残った同じ種類の穴

残る2件も、Galeraがサーバー間でデータをそろえる「同期（SST）」のまわりにあった、同じ系統の不備です。CVE-2026-48163はデータ同期に使うwsrep_sst_rsyncの処理で、CVE-2026-48165は実行中に変更できる設定値の扱いで、それぞれ外部から渡された値が安全に処理されていませんでした。いずれもCVSSは8.0で、悪用には一定の条件が要るものの、放置すればコマンド実行につながり得ます。これら3件がまとめて1回の修正リリースで塞がれた形です。

自分のMariaDBは更新が必要か（バージョン別早見表）

いま使っているバージョンは、mariadbd --versionや、データベースに接続してSELECT VERSION();と打つと確認できます。下の表で、自分の番号がどの系統に当てはまるかを照合してください。修正版はそれぞれの系統ごとに用意されています。

表の「優先度・高」は、あくまでGaleraクラスタで運用している場合の話です。1台だけの単独サーバーであれば、最高スコアのCVE-2026-49261そのものは該当しません。とはいえ同じリリースでは、Galera以外の細かな不備（監査ログや文字コードの処理など）も併せて直っているため、単独運用でも通常の更新サイクルの中で上げておくのが望ましい対応です。

いま取るべき対応

Galeraクラスタを運用しているなら、最優先で各系統の修正版（10.6.27／10.11.18／11.4.12／11.8.8／12.3.2）へ更新します。これが根本対策です。クラスタはノードを1台ずつ順に更新していく「ローリングアップグレード」で、サービスを止めずに上げられます。

すぐに更新できない場合の当座の手当ては2つあります。1つは、問題の通知機能を一時的に切ること（wsrep_notify_cmdの設定を外す）。もう1つは、クラスタが内部通信に使うポート（4567・4568・4444）を、信頼できないネットワークから遮断することです。そもそもGaleraの通信網は外部に晒すべきものではなく、ファイアウォールで参加サーバー同士に限定するのが基本です。ただしこれらは時間稼ぎであり、根本的にはバージョンの更新が必要です。今のところ実際の攻撃は確認されていませんが、修正の公開後は穴の場所が把握されやすくなるため、先送りはそのまま危険の蓄積になります。

技術的に見ると、なぜ外部の値がコマンドになるのか

今回の3件はいずれも、「外から来た文字列を、命令を組み立てる材料にそのまま流し込んだ」ことが原因です。プログラムが別のコマンドを呼び出すとき、人間が読む1本の文字列としてつなげてしまうと、その中に紛れた記号が命令の区切りとして解釈され、意図しない処理が走ります。これを避けるには、外部由来の値は命令と切り離して「ただのデータ」として渡す、あるいは危険な記号を無害化（エスケープ）してから使う必要があります。

この「外部入力をコマンドに混ぜてしまう」失敗は、特定の製品に限った話ではありません。たとえば、ファイル共有ソフトのSambaでも、パスワード変更スクリプトに渡す値の扱いから認証なしでコマンドを実行される脆弱性が見つかっています。便利な「外部スクリプトを呼ぶ」機能ほど、渡す値の検証が甘いと一気に乗っ取りの入口になります。AIが書いたコードをそのまま動かす場面が増える中で、入力をそのまま命令にしてしまう類の穴は、今後も繰り返し問われる論点です。

Galeraのようにサーバー同士が自動で連絡を取り合う仕組みは、「相手のノードは信頼できる」という前提で作られがちです。しかしその前提は、クラスタの通信網に第三者が手を伸ばせた瞬間に崩れます。ノードの名前のような、一見すると無害な情報まで「外部から来る、信用できない値」として扱う設計が、こうした穴への根本的な備えになります。

参照元

• ▸ MariaDB.org - Community Server Corrective Releases（2026年5月27日）
• ▸ MariaDB 10.6.27 リリースノート（CVE一覧）
• ▸ NVD - CVE-2026-49261（wsrep_notify_cmd のOSコマンドインジェクション）
• ▸ NVD - CVE-2026-48165
• ▸ NVD - CVE-2026-48163
• ▸ Galera Cluster 公式サイト