原文

pgAdmin 4 9.16でのCVE-2026-12045の修正では、AIアシスタントのexecute_sql_queryツールに渡される、LLMから提供されたクエリがsqlparseによってトランザクション制御文ではない単一の文として正確に解析される必要があり、それをBEGIN TRANSACTION READ ONLYラッパー内で実行していました。しかし、sqlparseの文字列リテラルの字句解析はPostgreSQL自身のパーサーと異なる可能性があります。標準準拠文字列（standard_conforming_strings）がon（PostgreSQL 9.1以降のデフォルト）の場合、クォート直前のバックスラッシュはPostgreSQLにとって単なる文字ですが、sqlparseはそれをクォートのエスケープとみなします。したがって、SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' のようなペイロードはsqlparseのバリデータには単一のSELECT文として解析されますが、PostgreSQLではこれが4つの文として実行されます。隠されたCOMMITによって読み取り専用トランザクションが終了し、後続のROLLBACKは無効となります。これにより、CVE-2026-12045で対策された書き込み/RCE回避が再現され、同じ間接的プロンプトインジェクションの手法（攻撃者がAIアシスタントが読み取れる任意のオブジェクトにペイロードを植え付け、LLMがそれをツール呼び出しとして出力する方法）で悪用可能となります。初期の修正案ではpsycopgのexecute(..., prepare=True)を使用し、sqlparseの分類にかかわらずPostgreSQLのParseステップ（拡張クエリプロトコル）により複数文を拒否しようとしました。しかし、この修正案は期待どおりに機能しませんでした。psycopg3のPrepareManagerは接続のprepare_thresholdがNone（pgAdminではすべてのサーバー接続でデフォルト）であればprepare引数を無視し、単純クエリプロトコルにフォールバックします。この単純クエリプロトコルは回避を可能にする複数文対応経路であるため、この修正案では現実のデフォルト構成では対策できませんでした。最終的な修正では、AIアシスタントツールが開く専用の使い捨て読み取り専用接続に対してconn.prepare_threshold = 0を直接設定し、サーバーレベルの設定に依存せず強制的に拡張クエリプロトコルを利用させます。PostgreSQL 18の実環境で検証した結果、prepare_threshold=None（デフォルト）の場合はペイロードが成功して実行されましたが、prepare_threshold=0を設定すると「準備済みステートメントに複数コマンドを挿入できません」として拒否されました。本問題はpgAdmin 4の9.13から9.17未満のバージョンに影響を及ぼします。