pgAdmin 4 の AI アシスタントで読み取り専用の囲いが破られ書き込み・RCE に至る（CVE-2026-12045 の修正漏れ）

Critical（CVSS 9.0）に分類されるpgAdmin（PostgreSQL 公式の管理ツール） pgAdmin 4（AI アシスタントの execute_sql_query ツール）の脆弱性です。PostgreSQL の管理ツール pgAdmin 4 の AI アシスタント機能に、読み取り専用のはずの経路から書き込みや任意コード実行に至る欠陥がある。これは新種の欠陥ではなく、先行する CVE-2026-12045 に対して 9.16 で入った修正が、条件付きで迂回できたというものである。9.16 の修正は、LLM が組み立てて execute_sql_query ツールへ渡してくる SQL を、実行前に Python の sqlparse で構文解析し、トランザクション制御を含まない単一文であることを確かめてから BEGIN TRANSACTION READ ONLY で囲って実行する、という設計だった。迂回が成立するのは、sqlparse の文字列リテラルの読み方と PostgreSQL 本体の読み方が食い違うためである。PostgreSQL は 9.1 以降 standard_conforming_strings を on にしており、引用符の直前のバックスラッシュはただの文字として扱う。ところが sqlparse はこれを引用符のエスケープとみなす。NVD の記述が挙げている実例は SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' で、sqlparse から見れば単一の SELECT だが、PostgreSQL はこれを4つの文として実行する。密輸された COMMIT が読み取り専用トランザクションをそこで終わらせてしまい、囲いの末尾にあるはずの ROLLBACK は何もしない命令に変わる。つまり CVE-2026-12045 が塞いだはずの書き込み・RCE への道がそのまま戻る。攻撃の運び方も同じで、間接プロンプトインジェクションである。攻撃者は AI アシスタントが読みうる任意のオブジェクト（テーブルのコメント、カラム名、行の中身など）に文字列を仕込んでおき、LLM がそれをツール呼び出しとして出力する。この CVE の記述にはもう一段、実装者にとって重要な話が含まれている。最初に提案された修正案は psycopg の execute(..., prepare=True) を使い、PostgreSQL 側の Parse ステップ（拡張問い合わせプロトコル）に複数文を拒否させる、というものだった。これは提出されたままでは機能しない。psycopg3 の PrepareManager は、接続の prepare_threshold が None のとき prepare 引数を黙って無視するためで、pgAdmin では全サーバ接続の既定値がまさに None である（サーバごとの Prepare threshold 欄は管理者が明示的に設定しない限り空欄）。結果として psycopg3 は単純問い合わせプロトコルへ落ち、迂回が通る経路がそのまま残る。採用された修正は、AI アシスタントが開く読み取り専用の使い捨て接続に対して conn.prepare_threshold = 0 を直接設定し、サーバ側の設定に関係なく拡張問い合わせプロトコルを強制するものである。NVD の記述は実機の PostgreSQL 18 で検証したと明記しており、既定の prepare_threshold=None では上のペイロードが通り、prepare_threshold=0 を設定すると cannot insert multiple commands into a prepared statement で拒否されるとしている。影響範囲は pgAdmin 4 の 9.13 以上 9.17 未満である。CVSS は NVD の主評価が 9.0 Critical（AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H）、CNA 側の CVSS 3.1 も同じ 9.0 で一致しており、CVSS 4.0 では 9.4 Critical が付いている。CISA KEV への収載は 2026-08-26 時点で確認できていない。

pgAdmin 4 を 9.17 以降へ更新する。9.13 より前を使っている場合はこの CVE の対象外だが、その場合は先行する CVE-2026-12045 側の対象になりうるので、いずれにせよ最新へ上げるのが早い。すぐに更新できない場合の最も確実な緩和は、AI アシスタント機能を無効にすることである。この欠陥は execute_sql_query ツールの経路でしか成立しないので、機能を使っていない組織にとってはこれが実質的な回避策になる。運用面で押さえておきたいのは、この種の欠陥が「AI に渡すデータは信頼できない入力である」という一点に尽きるということである。攻撃者は pgAdmin に直接触る必要がなく、AI アシスタントが読みにいくテーブルのコメントや行の中身に文字列を置いておけばよい。したがって、AI アシスタントを使う接続には本番の書き込み権限を持つロールを与えず、専用の読み取り専用ロールを割り当てる運用が有効である。これはアプリ側の修正とは独立に効く多層防御になる。もうひとつ、この CVE から一般化して持ち帰れる教訓がある。「アプリ側のパーサで検証してからデータベースへ渡す」という設計は、2つのパーサの解釈が完全に一致していないと成立しない。sqlparse と PostgreSQL のように、実装が別なら食い違いは原理的に残る。安全側の設計は、検証を諦めて実行系そのものに複数文を拒否させること、つまりここで採用された prepare_threshold=0 のように、プロトコルの段階で構造的に不可能にすることである。自分のコードで同種の「事前検証つきの SQL 実行」を持っているなら、同じ観点で見直す価値がある。

pgAdmin（PostgreSQL 公式の管理ツール） pgAdmin 4（AI アシスタントの execute_sql_query ツール） を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-17351）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。