CVE-2026-17566

概要

pgAdmin 4のImport/Export Dataツールは、ユーザーが指定したSQLクエリをJinjaテンプレートに補間してpsqlの`\copy (...)`コマンドラインを構築し、レンダリングされた行を`--command`経由でpsqlに渡します。攻撃者が`(...)`ラッパーから抜け出すのを防ぐため、`create_import_export_job()`（ルート`POST /import_export/job/<sid>`、通常広く付与される`tools_import_export_data`権限のみで保護）は、手書きの括弧バランスチェッカー`_is_query_parens_balanced()`でクエリを検証していました。このチェッカーは、単一引用符の前のバックスラッシュ（`\'`）を常に引用符のエスケープとして扱っていました。つまり、`standard_conforming_strings`がオフであるかのように扱っていました。PostgreSQLは9.1（2010年）以降、`standard_conforming_strings`をデフォルトでオンにしており、これはpgAdmin 4が現在サポートするすべてのPostgreSQLバージョン（13〜18）のデフォルトです。このデフォルトでは、psql自身の`\copy`トークナイザーは`\`を通常の文字として扱うため、その直後の単一引用符は文字列リテラルを閉じます。`SELECT 'a\') TO PROGRAM 'echo pwned' x'`のようなクエリは、pgAdminのチェッカーによって「バランスが取れている」と受け入れられました（チェッカーは`）`がまだ文字列内にあると認識していました）。一方、実際にレンダリングされたコマンドラインを通じて実行されるpsqlは、その時点で文字列を閉じ、続く`）`をラッピングされた`\copy (...)`サブクエリの終端として扱うため、攻撃者が選択した`TO PROGRAM '<command>'`句が露出し、psqlはそれを`popen()`経由で実行します。これは、同じ行の後半で後続の構文エラーが発生するかどうかとは無関係です。これはCVE-2025-12762/CVE-2025-13780（PLAIN形式ダンプ復元中のpsqlメタコマンド/COPYインジェクションによるRCE）と同じクラスのバグであり、別のモジュール（RestoreではなくImport/Export Data）で独立して書かれた防御策を通じて到達し、その防御策には独自の異なるロジックバグ（BOMによって無効化された正規表現アンカーではなく、逆転したバックスラッシュエスケープのセマンティクス）がありました。この修正は、クエリ内の単一引用符で囲まれた文字列内のバックスラッシュを完全に拒否するものであり、psqlの2つの可能な解釈のいずれかを選択するものではありません。これは意図的に保守的です。`\`の正しい解釈はターゲットサーバーの`standard_conforming_strings`設定に依存し、チェッカーは検証時にそれを確実に知ることができないため、推測するよりもクエリを拒否する方が安全です。この問題はpgAdmin 4に影響します：9.18より前の`_is_query_parens_balanced()`の導入時から。

• CVE-2026-17566PoC

  pgAdmin 4 インポート/エクスポート RCE (CVE-2026-17566) PoC - バックスラッシュエスケープの不一致によるTO PROGRAMインジェクション