PYSEC-2026-2580

Summary

SQLChatAgent in langroid ships a _validate_query defense-in-depth layer whose _DANGEROUS_SQL_PATTERNS regex blocklist enumerates dangerous SQL primitives by specific function name. The list misses the canonical PostgreSQL filesystem-disclosure family pg_read_file(), pg_stat_file(), pg_ls_logdir(), pg_ls_waldir(), pg_current_logfile() (and similar SELECT-shaped functions in the same family). It also leaves SQL Server OPENDATASOURCE and SQLite ATTACH '<file>' AS x (DATABASE keyword omitted) unblocked.

An attacker able to shape the LLM's generated SQL (directly via prompt input or transitively via prompt-injection in data the LLM ingests) can read arbitrary files from the PostgreSQL host through ordinary SELECT queries, even with the agent's strict default configuration (allow_dangerous_operations=False, allowed_statement_types=['SELECT']). The payloads survive the statement-type allowlist (each is a SELECT) and pass through the regex blocklist (none of the function names match), then reach the live SQLAlchemy engine via SQLChatAgent.run_query.

Affected versions

langroid <= 0.63.0 (latest at the time of this report; PyPI release 2026-05-27). The vulnerable code path is langroid/agent/special/sql/sql_chat_agent.py::_validate_query, which consults the module-level _DANGEROUS_SQL_PATTERNS literal at sql_chat_agent.py:113-141.

Privilege required

Any caller able to influence the LLM-generated RunQueryTool.query string that reaches SQLChatAgent.run_query. In a typical deployment this is any client of a SQLChatAgent-backed service, or any upstream data source whose content the LLM is asked to read and summarise. No PostgreSQL credentials are required from the attacker; the agent holds them.

Vulnerable code

langroid/agent/special/sql/sql_chat_agent.py:113-141 (the _DANGEROUS_SQL_PATTERNS literal) and sql_chat_agent.py:546-615 (the _validate_query method that consults it):

#...