PT-2026-56062 · Pypi · Langroid

Publicado

2026-07-06

·

Atualizado

2026-07-06

·

CVE-2026-54760

CVSS v4.0

9.3

Crítica

VetorAV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

SQLChatAgent validate query dangerous-pattern regex is bypassable via quoted/commented/qualified function names

Summary

The SQLChatAgent SQL-injection mitigation, with default allow dangerous operations=False, combines a raw-text regex blocklist ( DANGEROUS SQL PATTERNS) with a sqlglot SELECT-only statement allowlist. The blocklist entries that target callable functions require the function name to be immediately followed by s*(.
PostgreSQL accepts the same call with the name separated from ( by a quoted identifier, an inline comment, or schema qualification. These forms evade the regex, still parse as SELECT, and execute the same PostgreSQL function. This restores the pg read file server-side file-read primitive that the prior CVE-2026-25879 / GHSA-pmch-g965-grmr fix was meant to block: the parent advisory fixed a missing pg read file blocklist entry, while this report shows that the added regex is bypassable.

Affected Code

Tested against current main commit:
6e8e7b2bb23ec04c1c25be479f16b8cc9a4f8796
The current source still contains:
python
re.compile(r"bpg (read|stat|ls|current logfile)[A-Za-z0-9 ]*s*(", re.IGNORECASE)
validate query checks the raw query against DANGEROUS SQL PATTERNS, then parses with sqlglot and allows SELECT statements. The dangerous-call check is raw text, not normalized AST function-name matching.

Root Cause

The current mitigation treats dangerous PostgreSQL function calls as a raw-text regex problem. The regex requires the pg ... function token to be followed directly by optional whitespace and (, but PostgreSQL accepts equivalent calls through quoted identifiers, comments, and schema-qualified names. Because validate query only uses sqlglot to enforce the top-level statement type, those normalized function names are never checked after parsing.

Auth Boundary

The boundary is the default SQLChatAgent safety policy between attacker-influenced SQL generation and database operations that can read server-side files. With allow dangerous operations=False, a user or prompt that influences generated SQL should not be able to bypass the guard and execute PostgreSQL file-read functions such as pg read file.
This is not a new unauthenticated endpoint or product-wide SQL injection; it applies when untrusted user content can influence SQLChatAgent's generated SQL.

Reproduction

The local harness uses the current sql chat agent.py, extracts the real shipped dangerous regex list, validates the queries with real sqlglot==30.8.0, then executes the accepted bypasses against a local throwaway PostgreSQL 16 container.
Transcript excerpt:
text
CONTROL  "SELECT pg read file('/etc/passwd')" -> REJECTED: matches 'bpg (read|stat|ls|current logfile)[A-Za-z0-9 ]*s*('
BYPASS  'SELECT "pg read file"('/etc/passwd')' -> ALLOWED (validator returned None -> would execute)
BYPASS  "SELECT pg read file/**/('/etc/passwd')" -> ALLOWED (validator returned None -> would execute)
BYPASS  'SELECT pg catalog."pg read file"('/etc/passwd')' -> ALLOWED (validator returned None -> would execute)

=== Part B: real PostgreSQL execution of the bypass ===
connected; is superuser=t
 executed bypass 'SELECT "pg read file"('<file>')' -> file contents returned: 'LANGROID SAFE MARKER ...'
 executed bypass "SELECT pg read file/**/('<file>')" -> file contents returned: 'LANGROID SAFE MARKER ...'
 executed bypass 'SELECT pg catalog."pg read file"('<file>')' -> file contents returned: 'LANGROID SAFE MARKER ...'

RESULT: VULNERABLE
The control query is blocked by the current regex, while all three equivalent PostgreSQL forms are allowed by the validator and return the mounted proof file contents from a real PostgreSQL server. The LANGROID SAFE MARKER ... value is a harmless marker generated inside the throwaway local container for this proof.

Impact

On a deployment using SQLChatAgent against PostgreSQL with a role able to call pg read file (superuser, or a role granted pg read server files), an attacker who can influence LLM-generated SQL can coerce the agent into emitting one of the obfuscated queries and read files accessible to the PostgreSQL server process through pg read file.
This is the same impact and precondition shape as the published pg read file advisory, but it targets the bypassability of the current regex-based fix rather than the pre-fix absence of a pg read file block.
Severity: High by parity with the published parent advisory; not Critical. CWE-184 leading to server-side file read.

Suggested Fix

Do not rely on raw-text regex matching for dangerous-call detection. After the existing sqlglot parse, walk the AST and reject any function invocation whose normalized, unquoted, schema-stripped, case-folded name is in a dangerous set such as pg read file, pg read binary file, pg ls dir, pg stat file, lo import, lo export, load file, or load extension.
Also recommend running SQLChatAgent with a least-privilege database role that lacks pg read server files.

Correção

SQL injection

Path traversal

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
dbugs@ptsecurity.com

Enumeração de Fraquezas

CWE-89CWE-22

Identificadores relacionados

CVE-2026-54760
GHSA-6XC5-4R68-67FC

Produtos afetados

Langroid