JVNDB-2026-027059

pgAdmin ProjectのpgAdmin 4における複数の脆弱性

pgAdmin 4のインポート/エクスポートデータツールは、ユーザー提供のSQLクエリをJinjaテンプレートに埋め込み、psqlの--commandオプション経由で実行するpsqlの\copy (...)コマンドラインを生成します。攻撃者がこの(...)ラッパーから抜け出すのを防ぐため、create_import_export_job()（ルートPOST /import_export/job/＜sid＞、通常はtools_import_export_data権限で制限）は、手書きの括弧のバランスチェック関数_is_query_parens_balanced()でクエリの検証を行っていました。このチェック関数は、シングルクォート前のバックスラッシュ(\')をクォートのエスケープと常にみなしており、すなわちstandard_conforming_stringsがオフの場合の動作だと仮定していました。しかしPostgreSQLは、9.1(2010)以降（pgAdmin 4が現在サポートしているバージョン13〜18のすべてのデフォルト）でstandard_conforming_stringsをオンにしており、このデフォルト設定下ではpsqlの\copyトークナイザーは\を特別視せず、直後の単一引用符で文字列リテラルを終了します。したがって、例えばSELECT 'a\') TO PROGRAM 'echo pwned' x'のようなクエリは、pgAdminのチェック関数では「バランスが取れている」と受け入れられていました（閉じ括弧 ) が文字列内にあると誤認していたため）一方、実際にレンダリングされたコマンドラインでpsqlが実行されると、その時点で文字列が閉じられ、その後の ) が\copy (...)のサブクエリの終了と解釈され、攻撃者指定のTO PROGRAM '＜command＞'句がpopen()経由で実行されてしまいます。これは、CVE-2025-12762/CVE-2025-13780（PLAINフォーマットダンプ復元時のpsqlメタコマンド/COPYインジェクションによるRCE）と同じ種類の脆弱性であり、別モジュール（Restoreではなくインポート/エクスポートデータ側）にあった独自の防御ロジックに含まれていた逆のバックスラッシュエスケープ解釈のバグ（BOMを回避した正規表現アンカーの問題とは異なる）によるものです。修正では、psqlの2通りの解釈を選ぶのではなく、クエリ内のシングルクォートで囲まれた文字列内にバックスラッシュがあれば即座に拒否するようにしました。これは意図的に保守的な対応であり、\の適切な解釈はサーバー側のstandard_conforming_strings設定によって異なり、検証時にチェッカーがそれを確実に知ることができないため、推測よりもクエリを拒否したほうが安全だからです。この問題は、_is_query_parens_balanced()が導入される9.18以前からのpgAdmin 4に影響しています。

pgAdmin Project

• pgAdmin 4 9.18 未満

・当該ソフトウェアが扱う全ての情報が外部に漏れる可能性があります。
・当該ソフトウェアが扱う全ての情報が書き換えられる可能性があります。
・当該ソフトウェアが完全に停止する可能性があります。

リリース情報、またはパッチ情報が公開されています。参考情報を参照して適切な対策を実施してください。

1. 入力の誤った解釈(CWE-115) [その他]
2. OSコマンドインジェクション(CWE-78) [その他]

1. CVE-2026-17566

1. National Vulnerability Database (NVD) : CVE-2026-17566
2. 関連文書 : OS command injection in Import/Export Data via backslash-escape mismatch in the query guard (CVE-2026-17566)  Issue #10213  pgadmin-org/pgadmin4
3. 関連文書 : fix(security): reject ambiguous backslash-escape in import/export que…  pgadmin-org/pgadmin4@1496fab  GitHub

• [2026年08月06日]
    掲載