pgAdmin 4の脆弱性15件、共用のサーバーモードは9.19へ

社内のサーバーにpgAdminを1台立てて、何人かがブラウザから使っていませんか。その形なら、10月29日に出たpgAdmin 4 9.19の修正15件は、ほぼ自分ごとです。手元のPCで1人で使うデスクトップ版なら、急ぐ理由はずっと少なくなります。

ただ、共用の形では、9.19は上げればすぐ終わる更新ではありません。上げると止まる接続と、上げても残る設定があります。

クリティカルの2件は、ログイン画面とデータの書き出し

開発チームは9.19で、136件の不具合の修正と新機能に加え、15件の脆弱性（CVE-2026-116238〜CVE-2026-116252）を直しました。CVSS v4.0でクリティカルとされたのは2件です。

1件目のCVE-2026-116238（9.2）は、ログインの失敗の回数制限を回避できる問題です。サーバーモードのpgAdminは、内部のアカウントを既定で3回の失敗でロックします。その制限をすり抜けられ、アカウントを持たない攻撃者でも、管理者を含む内部のアカウントのパスワードを何度でも試せました。既定の設定のままで当たります。

2件目のCVE-2026-116241（9.4）は、データのインポート・エクスポートの機能からのOSコマンドインジェクションです。クエリの結果を書き出す処理に細工をすると、pgAdminが動くホストで、pgAdminを動かすOSのアカウントとしてコマンドを実行できました。悪用にはpgAdminへのログインが要りますが、この機能の権限は管理者でない利用者にも既定で付いています。

2件が重なると、ログイン画面が外から見えるpgAdminでは、パスワードを当てた人がホストでコマンドを動かす道筋も考えられます。開発チームがそう説明しているわけではありませんが、ログイン画面をインターネットに出している会社は、今日のうちに上げる理由になるでしょう。

15件のうち12件は、サーバーモードの会社に影響する

pgAdminには2つの動かし方があります。サーバーモードは、Webアプリとして1台に置き、利用者がログインして使う形です。利用者ごとにファイルの置き場所が分かれ、サーバーのファイル全体には触れません。デスクトップモードは、手元のPCで1人が使う形です。

公式の文書によると、v2からはサーバーモードが既定で、デスクトップのアプリで動かすときだけ自動で切り替わります。公式のコンテナ（dpage/pgadmin4）も、起動時にログイン用のメールアドレスとパスワードを決める、ログイン画面のある形です。

右の列は、各CVEの説明での扱いです。12件は、説明に「サーバーモード」の問題とあるか、デスクトップモードは当たらない・変わらないと記載があります。では残る3件はどうか。書き出しの件とセッションの件の2つは、ログインと複数の利用者を前提にした中身なので、デスクトップ版で困る場面は少ないと編集部は読んでいます。

サーバーモードでも、条件しだいで急ぐ度合いは下がります。共有の置き場所のファイルを実行させる件（CVE-2026-116243）は、Linuxなど（POSIX）ではpgAdmin経由で置いたファイルに実行の権限が付かず、Windowsで動かすサーバーモードなどで成り立ちます。シンボリックリンクの件（CVE-2026-116250）は、pgAdminとは別のOSのユーザーが置き場所に書き込める共有のストレージと、タイミングの競合が前提です。LDAPやKerberosの件（CVE-2026-116239）は、どちらかの認証を設定している場合だけです。

デスクトップ版で気にしたいのは、CVE-2026-116252です。CREATEDBの権限があるロールなら、接続の文字列のような名前のデータベースを作れます。その中のマテリアライズドビューをpgAdminで更新すると、psqlが別の接続先へつながり、保存してあるパスワードが渡ってしまいました。他人がデータベースを作れる共用のPostgreSQLに、デスクトップ版でつないでいる人も対象です。

復元と書き出しの機能からのコマンド実行は、1年で少なくとも6件

CVE-2026-116241は、7月31日に公表されたCVE-2026-17566の修正が足りなかったものです。さかのぼると、同じ型が続きます。

Windowsのバックアップと復元だけで起きたCVE-2025-12763（2025年11月13日）を含めると7件です。5月に入った括弧の検査は、7月と10月に続けて破られました。

どれも、ダンプの復元やデータの書き出しのように、pgAdminが外部のコマンドを動かす機能の周りで起きました。データベース名から接続先を差し替えるCVE-2026-116252も、バックアップや復元では以前に直っていて、マテリアライズドビューの更新が「残っていた呼び出し元」でした。

つまり、共用のpgAdminの置き方にもヒントがあります。入口を1つずつ閉じる修正が続いている以上、次も出ると考えて置き方を決めたほうが安全です。書き出しの機能の権限は、CVEの説明によると管理者でない利用者にも既定で付いています。「User Management」の画面の「Permissions」タブでは、ロールごとに権限を外せます。だから、書き出しを要る人だけに絞ると入口が減ります。共用のpgAdminは「ログインできる人が、ホストの上でコマンドを動かせるかもしれない箱」として、ほかのサーバーから切り分けます。今回の15件のうち4件は、pgAdminを動かすOSのアカウントが持つパスワードファイルやSSHの鍵、Kerberosの資格情報を、ほかの利用者が使えてしまう問題でした。そのアカウントの持ち物を減らすだけでも、次の脆弱性の被害は小さくなります。

9.19に上げると止まる接続、上げても残る共有

リリースノートには、上げる前と後に手を入れる所がいくつもあります。サーバーモードで使っている会社は、上げる前に次を読み合わせておくと、翌朝の「つながらない」を減らせます。

いちばん先に確かめたいのは、LDAPやKerberosでログインしている人です。これまで、同じ名前の内部のアカウント（最初に作った管理者を含む）として使えていた人は、9.19からそのアカウントに入れません。認証の方法ごとに自分のアカウントが要ります。管理者のアカウントをLDAPで使っていた会社は、上げたあと管理画面に入れなくなるおそれがあります。そこで、内部のアカウントのパスワードでログインできるかを先に確かめます。

• 接続のパスワードを外部のコマンドで取る設定（Password Exec Command）は、自由な文字列では動かなくなります。管理者がSERVER_PASSEXEC_COMMANDSに許すコマンドを名前で登録し、利用者はその名前から選ぶ形です。上げたあとの最初の起動で、登録と完全に一致するコマンドは名前に置き換わり、それ以外は消えて元に戻せません。設定が空なら置き換えは延期され、起動のたびに警告が出ます。
• 接続サービス（pg_service.confの定義）は、管理者がSERVER_MODE_ALLOWED_SERVICESに書いたものだけが使えます。既定は空なので、サービスを使う接続は書くまでつながりません。書いたサービスの資格情報は全員で使えるようになる点にも注意が要ります。
• pgAdminを動かすアカウントの~/.pgpassや~/.postgresqlの証明書、~/.sshの鍵や設定、ssh-agentに頼っていた接続は、接続ごとにファイルやパスワードを設定し直すまで動きません。
• パスワードファイルや証明書の場所が、利用者の置き場所の外（..やシンボリックリンクの先）にある接続も止まります。
• 共有された接続先は、持ち主のパスワードファイルを引き継がなくなります。各自が自分の接続に設定するか、全員で使うファイルをSHARED_STORAGEの置き場所に置き、Name:/.pgpassの形で指します。
• pg_dumpなどのコマンドの場所をSHARED_STORAGEの下に設定していた場合は、その設定が使えなくなります。
• Kerberosの資格情報の使い回しを止めるには、pgAdminとそのツールが使うlibpqを16以降にします。15以前だと、Windowsの統合認証（SSPI）やgssproxyを通じた使い回しが止まりません。
• 管理者でない人がすでに全員に共有した接続先は、上げても共有のまま残ります。起動時のログに1件ずつ警告が出るだけです。外すには、持ち主が共有を切るか、管理者が設定のデータベースでsharedの列を消します。
• Python 3.10以降にwheelで入れている場合は、Flask-Security-Too 5.8.3以降が必要です。

最後の2つは見落としやすいと編集部はみます。とくに共有の件は、上げた時点で「直った」と考えると、管理者でない人が作った共有が残り続けます。

サーバーモードの会社が今日から確認すること

1. 社内のpgAdminを洗い出します。サーバーに置いたもの、コンテナ（dpage/pgadmin4）で動かしているもの、開発者のPCのデスクトップ版を分けて書き出します。
2. ログイン画面がインターネットから見えるものは、先に接続元を社内やVPNに絞り、今日のうちに9.19へ上げます。
3. 上げる前に、config_local.pyでSERVER_PASSEXEC_COMMANDSとSERVER_MODE_ALLOWED_SERVICESを設定します。コンテナでは、PGADMIN_CONFIG_を頭に付けた環境変数で渡すか、/pgadmin4/config_local.pyを置きます。環境変数の値は最初の起動で設定のファイルに書かれるので、直したらdocker compose restartではなく、コンテナを作り直します。今の接続でサービスや外部のコマンドを使っているものも、先に一覧にしておきます。
4. 上げたら、起動時のログの共有の警告を見て、管理者でない人が作った共有を外します。書き出しの権限も、要る人のロールだけに残します。パスワードの変更でほかのセッションが切れるようになったので、気になるアカウントはパスワードを変えておきます。
5. pgAdminを動かすOSのアカウントから、要らないパスワードファイルやSSHの鍵を消します。
6. デスクトップ版の人は、ふだんの更新の流れで9.19に上げます。それまでは、他人がデータベースを作れる共用のPostgreSQLで、マテリアライズドビューの更新を避けます。

同じPostgreSQLの周りでは、10月にPgBouncerの脆弱性とJDBCドライバー（pgjdbc）の脆弱性も公表されました。データベースの周りのツールは、本体と別に版を台帳で追っておくと、次の告知のときに迷いません。