CVE-2026-17351

总结

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 则会将其作为四条语句执行：被走私的 COMMIT 结束了包装的只读事务，而尾部的 ROLLBACK 则成为空操作。这重新引入了 CVE-2026-12045 本应封堵的相同写入/RCE 绕过漏洞，并且可通过相同的间接提示注入投递方式触达（攻击者将载荷植入 AI 助手可能读取的任何对象中；LLM 将其作为工具调用发出）。一个初步的候选修复方案使用 psycopg 的 execute(..., prepare=True) 运行查询，意图强制 PostgreSQL 自身的 Parse 步骤（扩展查询协议）拒绝多语句文本，而不管 sqlparse 如何分类。该候选修复方案按提交方式并不奏效：当连接的 prepare_threshold 为 None 时（这是 pgAdmin 对每个服务器连接的默认设置——除非管理员显式设置，否则每个服务器的“Prepare threshold”字段为空），psycopg3 的 PrepareManager 会静默忽略 prepare 参数——psycopg3 会回退到简单查询协议，这正是该绕过所利用的同一多语句能力路径，因此该候选修复方案在任何真实世界的默认配置下都无法封堵任何漏洞。修正后的修复方案直接在 AI 助手工具打开的专用、一次性只读连接上设置 conn.prepare_threshold = 0，从结构上强制使用扩展查询协议，而不依赖于任何服务器级配置。已针对实时 PostgreSQL 18 实例进行验证：在 prepare_threshold=None（默认）行为下，该载荷可成功执行；而一旦在该连接上设置 prepare_threshold=0，载荷会被拒绝并提示“cannot insert multiple commands into a prepared statement”。此问题影响 pgAdmin 4：从 9.13 到 9.17 之前的所有版本。

• pgadmin-ai-assistant-sql-injection-cve-2026-17351-lexer-differential-bypassPoC

  概念验证（PoC），演示通过 sqlparse/PostgreSQL 词法分析器差异在 pgAdmin 4 的 AI 助手中实现 CVE-2026-17351 SQL 注入绕过，并包含间接提示注入的投递。