CVE-2026-50180: Langroid Framework SQL Injection Flaw

CVE-2026-50180 Overview

CVE-2026-50180 affects Langroid, a framework for building large-language-model-powered applications. Versions prior to 0.64.0 ship an incomplete _DANGEROUS_SQL_PATTERNS regex blocklist inside SQLChatAgent._validate_query. The blocklist omits the PostgreSQL filesystem-disclosure function family, including pg_read_file(), pg_stat_file(), pg_ls_logdir(), pg_ls_waldir(), and pg_current_logfile(). It also fails to block SQL Server OPENDATASOURCE and SQLite ATTACH '<file>' AS x. Attackers who influence the LLM-generated SQL can read arbitrary files from the database host through ordinary SELECT queries. The issue is tracked as [CWE-22] Path Traversal.

Critical Impact
Attackers can read arbitrary files from the PostgreSQL host through SELECT queries even when allow_dangerous_operations=False and allowed_statement_types=['SELECT'] are set.

Affected Products

Langroid versions prior to 0.64.0
Applications using SQLChatAgent with PostgreSQL, SQL Server, or SQLite backends
LLM pipelines that ingest untrusted content processed by SQLChatAgent.run_query

Discovery Timeline

2026-07-10 - CVE-2026-50180 published to NVD
2026-07-10 - Last updated in NVD database

Technical Details for CVE-2026-50180

Vulnerability Analysis

The vulnerability resides in the defense-in-depth layer _validate_query within SQLChatAgent. The layer enforces two controls: a statement-type allowlist and a regex blocklist of dangerous SQL primitives. The regex blocklist enumerates dangerous functions by name rather than by capability class. This design misses entire families of read-oriented functions that expose the host filesystem through the database engine.

On PostgreSQL, functions such as pg_read_file() and pg_stat_file() return file contents or metadata from the server host. Because these functions are invoked inside a SELECT statement, they satisfy the statement-type allowlist. Their names do not appear in the regex blocklist, so _validate_query returns success. The query then reaches the live SQLAlchemy engine through SQLChatAgent.run_query and executes with the privileges of the database role.

Additional bypasses exist for SQL Server via OPENDATASOURCE and for SQLite via ATTACH '<file>' AS x when the optional DATABASE keyword is omitted. Both primitives extend the same filesystem-disclosure impact to non-PostgreSQL backends.

Root Cause

The root cause is an incomplete blocklist. _DANGEROUS_SQL_PATTERNS enumerates dangerous primitives by specific function name rather than modeling capability categories such as file I/O, external data sources, or database attachment. Any read-oriented function that produces a SELECT-shaped statement bypasses both defense layers.

Attack Vector

An attacker shapes the SQL generated by the LLM. This is possible directly through prompt input or transitively via prompt injection embedded in data the LLM ingests. The attacker instructs the model to emit a SELECT statement invoking pg_read_file('/etc/passwd') or an equivalent function. The payload passes _validate_query, reaches the SQLAlchemy engine, and returns file contents to the attacker channel. No authentication to Langroid is required when the deployment exposes an unauthenticated chat interface. See the GitHub Security Advisory for the maintainer's technical analysis.

Detection Methods for CVE-2026-50180

Indicators of Compromise

Database query logs containing calls to pg_read_file, pg_stat_file, pg_ls_logdir, pg_ls_waldir, or pg_current_logfile
SQL Server audit records referencing OPENDATASOURCE originating from Langroid application accounts
SQLite ATTACH statements referencing filesystem paths issued by application service accounts
Unexpected SELECT statements produced by LLM agents that reference absolute filesystem paths

Detection Strategies

Enable PostgreSQL log_statement = 'all' on hosts running SQLChatAgent and alert on the filesystem-disclosure function family
Instrument SQLChatAgent.run_query to log the pre-execution SQL text and compare against an expanded deny list
Correlate LLM prompt content with subsequent SQL execution to identify prompt-injection driven queries

Monitoring Recommendations

Forward database audit logs to a centralized analytics platform for retention and query-time detection
Monitor for anomalous file-path strings inside application-generated SQL
Track Langroid package versions across deployments and alert on any host running a release earlier than 0.64.0

How to Mitigate CVE-2026-50180

Immediate Actions Required

Upgrade Langroid to version 0.64.0 or later where the blocklist has been extended
Restrict the PostgreSQL role used by SQLChatAgent so that filesystem functions require privileges the role does not hold
Revoke EXECUTE on pg_read_file, pg_stat_file, and related functions from application roles
Audit historical database logs for prior invocation of the affected function families

Patch Information

Version 0.64.0 contains the fix. The maintainer commit is available at the GitHub Commit Overview. The patch extends _DANGEROUS_SQL_PATTERNS to cover the PostgreSQL filesystem-disclosure family, OPENDATASOURCE, and the SQLite ATTACH primitive without the DATABASE keyword.

Workarounds

Run SQLChatAgent against a database role with no access to filesystem functions or external data sources
Place the database engine on a host with no sensitive files readable by the database service account
Add an application-layer filter that rejects any generated SQL referencing pg_read_file, pg_stat_file, OPENDATASOURCE, or ATTACH
Isolate the database host on a segmented network to limit lateral impact if disclosure occurs

bash

# Configuration example: revoke filesystem function access from application role
REVOKE EXECUTE ON FUNCTION pg_read_file(text) FROM langroid_app;
REVOKE EXECUTE ON FUNCTION pg_read_file(text, bigint, bigint) FROM langroid_app;
REVOKE EXECUTE ON FUNCTION pg_stat_file(text) FROM langroid_app;
REVOKE EXECUTE ON FUNCTION pg_ls_logdir() FROM langroid_app;
REVOKE EXECUTE ON FUNCTION pg_ls_waldir() FROM langroid_app;
REVOKE EXECUTE ON FUNCTION pg_current_logfile() FROM langroid_app;