データベース中継ソフト「ProxySQL」に最悪評価10.0の脆弱性 CVE-2026-48772、全利用者はv3.0.9へ即更新を
MySQLやPostgreSQLへのアクセスを振り分ける人気ソフト「ProxySQL」に、攻撃者が接続元を偽ってアクセス制限を突破できる最悪評価10.0の欠陥など重大な2件が見つかりました。どちらも認証なしで悪用でき、初期設定のままだと無防備です。対象バージョンと、安全な3.0.9への更新手順をまとめます。
堀川 慎
Backend Engineer / AWS / Django / Go
MySQLやPostgreSQLへのアクセスを振り分ける人気ソフト「ProxySQL」に、攻撃者が接続元を偽ってアクセス制限を突破できる最悪評価10.0の欠陥など重大な2件が見つかりました。どちらも認証なしで悪用でき、初期設定のままだと無防備です。対象バージョンと、安全な3.0.9への更新手順をまとめます。
MySQLやPostgreSQLといったデータベースへのアクセスを振り分ける人気ソフト「ProxySQL」に、重大な脆弱性が2件見つかりました。1件は危険度を示すスコアが最大の10.0（10点満点）で、攻撃者が自分の接続元を偽ってアクセス制限をすり抜けられるというものです。もう1件は、ログインする前の段階でサーバーのメモリを壊し、停止させられる恐れがあります。
どちらも認証（ログイン）なしで悪用できるのが厄介な点です。開発元のsysownは2026年6月4日に修正版「ProxySQL 3.0.9」を公開し、利用者にすぐ更新するよう呼びかけています。脆弱性の番号はCVE-2026-48772とCVE-2026-48773です。この記事では、どんなソフトが対象で、何が危ないのか、そして自分の環境が該当するかの確認方法までをまとめます。
そもそもProxySQLとは。データベースの「交通整理役」
ProxySQLは、アプリケーションとデータベースの間に置く「中継役」のソフトです。Webサービスやアプリが大量のアクセスを受けると、データベースへの問い合わせも一気に増えます。そのとき、問い合わせを複数のデータベースに振り分けたり、「データを書き込む処理は親サーバーへ、読み取りだけの処理は複製サーバーへ」と仕分けたりして、全体がパンクしないように交通整理するのがProxySQLの役目です。
無料で使えるオープンソースソフトでありながら処理性能が高く、アクセスの多いサービスの裏側で広く使われています。MySQLやその派生（MariaDB、Percona、AWSのAuroraなど）に加え、近年はPostgreSQLにも対応しました。つまり、名前を聞いたことがなくても、あなたが使っているネットサービスのデータベースの前にProxySQLが置かれている、という状況は珍しくありません。
こうした「データベースの入り口を守る場所」だからこそ、ここに穴が空くと影響が大きくなります。データの読み書きの仕分けや、誰がアクセスしてよいかの判定を、ProxySQLが一手に引き受けているからです。データベースそのものの守り方については、主キー設計を1000万件で検証した記事でも触れています。
見つかったのは重大な2つの欠陥
今回公表されたのは、性質の異なる2つの脆弱性です。まず全体像を表で整理します。
| CVE番号 | 危険度 （CVSS） | 何が起きるか | ログイン | 対象バージョン |
|---|---|---|---|---|
| CVE-2026-48772 | 10.0 （最大） | 接続元を偽り アクセス制限を突破 | 不要 | 2.0.0〜3.0.8 |
| CVE-2026-48773 | 9.8 （緊急） | ログイン前に メモリを破壊 | 不要 | 2.0.18〜3.0.8 |
CVSSとは脆弱性の深刻さを0〜10で表す国際的な指標で、数字が大きいほど危険です。米国の脆弱性データベース（NVD）はCVE-2026-48772を満点の10.0と評価しました（開発元のGitHub Advisoryでは9.1としており、評価機関によって多少の差があります）。もう一方のCVE-2026-48773も9.8で、いずれも「緊急」に分類される高さです。
誰が、何のために狙うのか
CVSSの数字だけでは「自分に関係あるのか」が分かりにくいので、もう少しかみ砕きます。今回の穴を実際に突くのは、インターネット越しにデータベースの入り口を探し回っている攻撃者です。ProxySQLは初期設定のままだと、どこからの接続でも「自己申告された接続元情報」をそのまま信じてしまう状態になっています。攻撃者にとっては、わざわざログイン情報を盗まなくても近づける格好の標的です。
彼らがすることは2つに分かれます。1件目の穴では、「自分は社内ネットワークの安全な場所から来た」と接続元を偽装して、本来は弾かれるはずのアクセス制限をすり抜けます。「この場所からだけ書き込みを許可する」「この範囲からの接続だけ親データベースに通す」といったルールを、嘘の住所で回避してしまうわけです。2件目の穴では、わざと壊れた最初のデータを送りつけ、ログイン画面にたどり着く前にProxySQLのメモリを破壊します。
この結果、サービスを使う一般の利用者から見れば、サイトやアプリが急に重くなったり、つながらなくなったりという形で被害が表面化します。システムを運用する企業側はもっと深刻で、アクセス制限が意味をなさなくなれば、本来は触れないはずのデータの読み書きを許してしまう恐れがあります。しかも接続元を偽られると、アクセス記録（ログ）にも偽の住所が残り、後から「誰がやったか」を追うのも難しくなります。データベースを狙う攻撃の手口は、Spring AIでログインなしにデータベースを操作された事例や、AIが書いたSQLでデータベースを乗っ取られた事例とも通じるものがあります。
2つの欠陥を詳しく見る
ここからは技術的な中身です。それぞれの穴が「なぜ成立するのか」を解説します。
CVE-2026-48772: 接続元アドレスを偽ってアクセス制限を突破
この脆弱性の舞台は「PROXYプロトコル」という仕組みです。これは、ロードバランサーなどを経由して接続が来たとき、「本当の接続元はこのIPアドレスですよ」と中継機器が伝えるための取り決めで、もともとはHAProxyが策定した規格です。ProxySQLはこの情報を受け取って、アクセス制限の判定に使います。
問題は、この規格に「接続元が不明（UNKNOWN）」というモードがあることです。規格では「UNKNOWNと書かれていたら、後ろに付いているアドレス欄は無視しなければならない」と明記されています。ところがProxySQLは、UNKNOWNと書かれていてもアドレス欄を読み取り、その値を本物の接続元として採用してしまっていました。開発元のセキュリティ勧告（GHSA-gw94-85m2-x8v2）によれば、攻撃者はこの仕様の取り違えを突いて、好きなIPアドレスを自分の接続元として申告できます。
さらに深刻なのが初期設定です。ProxySQLの設定項目mysql-proxy_protocol_networksは、初期値が'*'（すべて許可）になっています。これは「どこからの接続でもPROXYプロトコルの自己申告を受け付ける」という意味で、つまり初期設定のまま外部に開いていると、誰でもこの偽装が使える状態です。接続元IPを根拠にした「読み書きの振り分け」「特定の範囲だけにデータ定義の変更を許す」といったルールが、すべて無効化される恐れがあります。
CVE-2026-48773: ログイン前にサーバーを壊せるメモリ破壊
もう1件は、データベースに接続する一番最初のやり取りに潜んでいます。クライアントがProxySQLにつなぐと、まず「これからこのくらいの大きさのデータを送ります」という宣言（パケットの長さ）を送ります。ProxySQLはその数値を信じて受信用の領域を用意するのですが、ここで攻撃者が実際よりもはるかに大きな長さを申告すると、用意された32KBの入力用領域をはみ出してメモリに書き込みが起きてしまいます。これがCWE-787（領域外への書き込み）と呼ばれる、典型的なメモリ破壊の脆弱性です。
この処理はログイン認証よりも前に走るため、正しいユーザー名やパスワードを一切持っていなくても攻撃が成立します。MySQL系だけでなくPostgreSQL側の入り口でも同じ問題が起きると報告されており、対象が広いのも特徴です。メモリ破壊はまずサーバーのクラッシュ（サービス停止）につながり、条件次第ではより深い悪用に発展する危険もあります。ProxySQL 3.0.9では、この欠陥に加えて大きなパケットを巡る別の不具合（二重解放）も同時に修正されています。
自分の環境は危ないのか。バージョン別の早見表
使っているProxySQLのバージョンは、コマンドproxysql --versionで確認できます。下の表で対応する行を探してください。
| 使用中のバージョン | CVE-2026-48772 | CVE-2026-48773 | 対応の優先度 |
|---|---|---|---|
| 2.0.0〜2.0.17 | 該当 | 対象外 | 高（即更新） |
| 2.0.18〜3.0.8 | 該当 | 該当 | 最優先（即更新） |
| 3.0.9 以降 | 修正済み | 修正済み | 対応不要 |
| 1.x（旧系列） | 対象外 | 対象外 | 別途サポート終了に注意 |
2.0.0〜3.0.8を使っているなら、少なくともどちらか一方、多くの場合は両方に該当します。修正は3.0.9で入りましたが、開発元は別系列を使う人向けに3.1.9や4.0.9にも同じ修正を反映しています。自分の系列に合った最新版を選んでください。
何をすればいいか。対策と更新の手順
いちばん確実な対策は、3.0.9以降へのアップデートです。パッケージ管理から導入している場合は、リポジトリを更新したうえでProxySQLのパッケージを入れ替え、サービスを再起動します。Dockerイメージを使っている場合は、タグを3.0.9以降に差し替えてコンテナを作り直してください。
事情があってすぐに更新できない場合は、被害を抑える応急処置として次の3つが有効です。1つ目は、設定項目mysql-proxy_protocol_networksを'*'のままにせず、ロードバランサーなど信頼できる機器のIP範囲だけに絞ること。2つ目は、ProxySQLが待ち受けるポートをインターネットに直接さらさず、ファイアウォールや社内ネットワーク内に閉じること。3つ目は、接続元IPを根拠にしているアクセス制限ルールを洗い出し、それだけに頼った設計になっていないか見直すことです。ただしこれらはあくまで時間稼ぎで、根本的な解決はバージョン更新だという点は変わりません。
なお、今回の2件は2026年6月19日時点で米CISAの「悪用が確認された脆弱性リスト（KEV）」には登録されておらず、実際に攻撃へ使われたという公的な報告も確認されていません。とはいえ、認証なしで悪用でき、初期設定が無防備という条件がそろっているため、公表後に狙われやすい部類です。様子見をせず早めに対応するのが安全です。
これまでの経緯
修正版の公開から脆弱性番号の正式登録までの流れは次の通りです。
| 日付 | できごと |
|---|---|
| 2026年6月4日 | 修正版 ProxySQL 3.0.9 を公開 |
| 2026年6月19日 | CVE-2026-48772／48773 が NVDで正式公開 |
PROXYプロトコルの偽装（CVE-2026-48772）は、研究者「addcontent」氏の報告がきっかけで修正されました。著名な研究者による検証用の攻撃コード（PoC）の一般公開は、現時点では確認されていません。
まとめ
ProxySQLはデータベースの入り口を預かる重要な部品で、そこに認証なしで突けるアクセス制限の突破（CVE-2026-48772）とメモリ破壊（CVE-2026-48773）の2つの穴が見つかりました。とくに前者は危険度が最大の10.0で、初期設定のまま外部に開いていると無防備です。
対象は2.0.0〜3.0.8と幅が広く、長く使い続けている環境ほど該当しやすいのが実情です。まずはproxysql --versionで自分のバージョンを確かめ、該当するなら3.0.9以降へ更新する。すぐ更新できないなら接続元の範囲を絞り、外部に直接さらさない。やるべきことはこの2点に尽きます。データベースの前段は普段あまり意識されない場所だからこそ、見落とさずに手を入れておきたい一件です。