Langroid SQLChatAgent Blocklist Bypass Leading to SQL-Based File Disclosure
First seen Jul 10, 2026 · Updated Jul 10, 2026
Langroid's SQLChatAgent uses an incomplete regex denylist to block dangerous SQL functions before executing LLM-generated queries against a live database. Because the denylist omits PostgreSQL file-reading functions (pg_read_file, pg_stat_file, etc.) and certain SQL Server/SQLite file-attach primitives, an attacker who can influence the generated SQL—directly or via prompt injection in ingested data—can craft ordinary SELECT statements that read arbitrary files from the database host, bypassing the agent's strict default safety configuration entirely.
Technical Analysis
SQLChatAgent enforces two safety layers: a statement-type allowlist restricting queries to SELECT, and a regex-based _DANGEROUS_SQL_PATTERNS blocklist matching specific dangerous function names before handing the query to SQLAlchemy's run_query. The blocklist is name-based and incomplete, missing an entire family of PostgreSQL filesystem-disclosure functions (pg_read_file, pg_stat_file, pg_ls_logdir, pg_ls_waldir, pg_current_logfile) as well as SQL Server OPENDATASOURCE and SQLite ATTACH variants that omit the DATABASE keyword. Because these payloads are syntactically SELECT statements, they pass the allowlist, and because their function names are absent from the regex, they pass the blocklist, reaching the live database engine unfiltered. The entry point is any surface where the LLM's SQL generation can be steered—user prompts or, more dangerously, untrusted data ingested by the agent that triggers prompt injection—allowing an attacker to exfiltrate arbitrary files from the host database server through a tool the agent believed was safely sandboxed. This crosses the trust boundary between 'agent-generated but constrained' SQL and 'arbitrary attacker-controlled' SQL, defeating the intended defense-in-depth model.
Affected Systems
Langroid
Detection Signatures
- SQL queries containing pg_read_file(, pg_stat_file(, pg_ls_logdir(, pg_ls_waldir(, or pg_current_logfile(
- SELECT statements referencing OPENDATASOURCE(
- ATTACH '<file>' AS <alias> without DATABASE keyword in SQLite contexts
- Unexpected file-path-like string literals inside SELECT queries generated by an LLM agent
- SQLChatAgent logs showing run_query executed against pg_catalog or system functions
- Anomalous outbound SELECT queries following ingestion of untrusted/external text into agent context
Remediation Steps
- 1
Upgrade Langroid
Update to Langroid version 0.64.0 or later, which patches the _DANGEROUS_SQL_PATTERNS blocklist to cover the missing function families.
- 2
Replace blocklist with allowlist-based query validation
Instead of enumerating dangerous function names, restrict generated SQL to a strict allowlist of permitted tables, columns, and functions relevant to the application's use case.
- 3
Apply least-privilege database credentials
Run the agent's database connection under a role without access to system catalog functions, file I/O privileges, or superuser-only functions like pg_read_file.
- 4
Sandbox or isolate the database host
Ensure the database server does not have access to sensitive files, and disable or revoke EXECUTE on filesystem-access functions for the application role.
- 5
Treat ingested data as untrusted for SQL generation
Apply prompt-injection defenses and input sanitization when any data the LLM ingests could influence SQL generation, not just direct user prompts.
- 6
Add runtime monitoring for anomalous SQL patterns
Log and alert on SELECT queries invoking uncommon system functions or referencing filesystem paths.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.