pgAdmin 脆弱性 CVE-2026-116241｜Import/ExportのOSコマンドインジェクション

今回の pgAdmin 脆弱性 CVE-2026-116241 は、PostgreSQL の定番管理ツール pgAdmin 4 にある OS コマンドインジェクションです。Import/Export Data（インポート/エクスポート）ツールを通じて、pgAdmin を動かしているホスト上で任意のコマンドが実行できてしまうもので、CVSS 3.1 で 9.9（Critical）、4.0 で 9.4。PostgreSQL が CVE を採番し、2026年10月30日に公表しました。影響は pgAdmin 4 の 9.19 未満すべてで、修正は 9.19 です。

未認証ではありませんが、ハードルは高くありません。成立の前提は「pgAdmin で Import/Export Data が使える通常のデータベースロール」で、その権限は既定で非管理者にも付与されます。しかもスコープが DB ロールからホストの OS へ変わる（S:C）ため、いちユーザーの操作が pgAdmin サーバー全体の侵害に直結します。開発ツールを狙う攻撃の全体像はサプライチェーン攻撃とは｜手口・防御ツール比較・npm 12の新機構まで実践解説に、よく似た DB 管理ツールの事例はphpMyAdmin 5.2.3 の WebAuthn 2FA バイパス、同じく外部コマンドへの注入はAWS SAM CLI の Terraform 連携に潜むコマンドインジェクションに整理しています。この記事は、何が起きるか・なぜ検査をすり抜けるか・どう直すかを、一次情報で整理します。攻撃を再現する具体的なクエリ（PoC）は載せません。

pgAdmin 脆弱性 CVE-2026-116241 で何が起きるか：Import/Export から OS コマンドへ

pgAdmin の Import/Export Data ツールは、クエリ結果をファイルへ書き出すときに、そのクエリを psql の \copy (...) TO というコマンドで包みます。ラッパーから抜け出されないように、pgAdmin はクエリの丸括弧が釣り合っているかを検査し、余計な閉じ括弧でラッパーを早く終わらせられないようにしているつもりでした。

ところが、この検査には穴がありました。一重引用符の文字列の中のバックスラッシュは弾くのに、二重引用符の識別子の中のバックスラッシュは弾かず、次に現れた二重引用符で識別子が閉じたものとして扱っていたのです。攻撃者が二重引用符の識別子の中にバックスラッシュを置くと、pgAdmin の検査は「ここで識別子が閉じ、括弧は釣り合っている」と判断します。

なぜ検査をすり抜けるのか：引用符の解釈のズレ

鍵は、pgAdmin の検査と psql の実際の解釈が食い違うことです。psql の \copy パーサは、接続のエスケープ文字を、トークンを開いた引用符に適用します。そのため、サーバー設定 standard_conforming_strings が off のとき、バックスラッシュでエスケープされた二重引用符（\"）は識別子を閉じません。

つまり、pgAdmin は「識別子はここで閉じ、丸括弧は釣り合っている」と見るのに、psql は「識別子はまだ続いている」と見る。この差のせいで、検査からは隠れていた閉じ丸括弧が \copy (...) のラッパーを早く終わらせ、続けて書かれた TO PROGRAM 句が実行されます。TO PROGRAM は psql がホスト上で外部コマンドを起動する機能なので、サーバーが文を弾くより前に、pgAdmin を動かしている OS アカウントの権限で任意コマンドが走ります。

成立条件は攻撃者の手の内にあります。standard_conforming_strings は通常のロールが自分の接続で off にできますし、Import/Export Data の権限は既定で非管理者に付与されています。特別な管理権限は要りません。CWE では CWE-78（OS コマンドインジェクション）と CWE-115（入力の誤解釈）に分類されています。

ここで効いているのは「同じ文字列を2つのパーサが別々に解釈する」という、インジェクション全般に共通する弱点です。pgAdmin はクエリを文字列として psql コマンドのラッパーに埋め込み、安全かどうかを自前の括弧チェックで判断します。しかし実際にそのクエリを動かすのは psql 側のパーサで、引用符やエスケープの扱いが pgAdmin の想定と一致している保証はありません。とくに今回は、standard_conforming_strings というサーバー側の設定によってバックスラッシュの意味が変わるため、pgAdmin が検証する時点では「このバックスラッシュがエスケープになるのか」を確実に知ることができません。確実に知れないものを「安全」と判断してしまったことが、すり抜けの本質です。だからこそ 9.19 の修正は、意味を推測して通すのではなく、二重引用符の識別子内のバックスラッシュを一律に拒否するという、保守的な方針を取っています。

どう直すか：9.19 へ更新し、Import/Export を絞る

恒久対策は、pgAdmin 4 を 9.19 以上へ更新することです。影響は 9.19 未満のすべて。修正は、一重引用符の文字列と同じように、二重引用符の識別子の中のバックスラッシュも拒否するものです。検証の時点ではバックスラッシュの意味がサーバー設定に依存して確実には分からないため、バックスラッシュ自体を弾く、という方針です。まず稼働中の版を確認します。

# 稼働中の pgAdmin 4 の版を確認する
pip show pgadmin4 2>/dev/null | grep -i version
# コンテナ運用ならイメージのタグ（例）
docker ps --format '' | grep -i pgadmin
# About ダイアログ（Help → About）でも版を確認できる

すぐに更新できない場合の緩和として、Import/Export Data を使えるロール・ユーザーを信頼できる範囲に絞ることが効きます（既定で非管理者にも付くため、不要なら外す）。あわせて、pgAdmin を動かす OS アカウントの権限と到達範囲を最小化しておくと、万一実行されたときの被害を小さくできます。ただし standard_conforming_strings を on に固定する運用は、攻撃者が自分の接続で off にできるため確実な回避にはなりません。確実なのは 9.19 への更新です。

影響範囲：サーバーモードの多人数運用が重い

この問題は pgAdmin のデスクトップ利用でも起こりえますが、影響が大きいのはサーバーモード（Web）で多人数が使う pgAdmin です。そこでは pgAdmin のホストが共有の管理基盤になっていることが多く、いちユーザーが OS コマンド実行を得ると、ほかの接続情報や保存された資格情報、同居するサービスまで被害が広がりかねません。本件は CVE-2026-17566 の修正バイパスで、同じ「文字列として外部コマンドのラッパーに埋め込み、引用符・エスケープの解釈差で抜け出す」構図の再来です。該当する運用では、更新の優先度を高く見積もるのが妥当です。

とくに注意したいのは、pgAdmin のホストが「接続先データベースへの鍵束」になっている点です。pgAdmin には複数の DB サーバーへの接続情報が保存され、サーバーモードではそれが共有されます。OS コマンド実行を一度得られると、攻撃者はそこを足がかりに、保存された接続情報や資格情報、同じホスト上の設定ファイルへ手を伸ばせます。つまり被害は「1つの DB」ではなく「pgAdmin が束ねるすべての接続」に及びうる、と見ておくのが安全です。更新までの間は、Import/Export を使える範囲を絞ると同時に、pgAdmin ホストから到達できるネットワークと保存済み資格情報を点検してください。

参照ソース

• CVE-2026-116241 公式記録（PostgreSQL 採番・CVEProject/cvelistV5）（CVSS 9.9・CWE-78/115・影響 <9.19・CVE-2026-17566 の修正バイパス）
• pgadmin-org/pgadmin4 Issue #10663（Import/Export Data のコマンド実行の報告）