CVE-2026-50180: 
Python vulnerability analysis and mitigation

CVE-2026-50180 is a SQL injection / path traversal vulnerability in the Langroid LLM application framework affecting the SQLChatAgent component. The _validate_query defense-in-depth layer uses a regex blocklist (_DANGEROUS_SQL_PATTERNS) that enumerates dangerous SQL primitives by exact function name, but omits the PostgreSQL filesystem-disclosure family (pg_read_file(), pg_stat_file(), pg_ls_logdir(), pg_ls_waldir(), pg_current_logfile(), and related functions), as well as SQL Server OPENDATASOURCE and SQLite ATTACH '<file>' AS x (without the DATABASE keyword). All versions of langroid up to and including 0.63.0 (PyPI release 2026-05-27) are affected; version 0.64.0 contains the patch. The vulnerability carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory).

The root cause is an incomplete blocklist (CWE-89: SQL Injection; CWE-22: Path Traversal) in langroid/agent/special/sql/sql_chat_agent.py at lines 113–141. The _DANGEROUS_SQL_PATTERNS list blocks specific PostgreSQL function names (e.g., pg_read_server_file, pg_read_binary_file, pg_ls_dir) but misses semantically equivalent near-name functions in the same family. Because each bypass payload is syntactically a SELECT statement, it also passes the statement-type allowlist (allowed_statement_types=['SELECT']), then reaches the live SQLAlchemy session.execute(text(query)) sink in SQLChatAgent.run_query. An attacker exploits this by influencing the LLM-generated SQL — either directly through user prompt input or transitively via prompt injection in data the LLM ingests — without needing any database credentials, since the agent holds them. A public proof-of-concept demonstrating live execution of all five bypass payloads against a transient PostgreSQL instance is included in the advisory (GitHub Advisory, Patch Commit).

Successful exploitation enables arbitrary file read from the PostgreSQL host: pg_read_file() can read PGDATA-relative or absolute paths (when the DB role is a superuser), exposing postgresql.conf, pg_hba.conf, ~/.pgpass, TLS private keys, and any file readable by the PostgreSQL OS user. Filesystem reconnaissance is also possible via pg_stat_file() (file metadata), pg_ls_logdir(), pg_ls_waldir(), and related functions. On MSSQL deployments, OPENDATASOURCE enables outbound reads to remote SQL Servers and UNC paths, providing an intranet pivot vector; on SQLite deployments with extended allowed_statement_types, ATTACH can read or write arbitrary SQLite files. The impact is primarily a high confidentiality breach with no direct integrity or availability impact (GitHub Advisory).

1. Identify target: Locate a service backed by SQLChatAgent from langroid ≤ 0.63.0 connected to a PostgreSQL database. No credentials are needed — the agent holds the DB connection.
2. Craft prompt injection payload: Inject a malicious instruction into any input the LLM processes — a user message, a document the agent retrieves, or data rows fed back into LLM history — instructing the LLM to generate a file-disclosure SQL query.
3. Trigger LLM SQL generation: Cause the LLM to produce a query such as SELECT pg_read_file('postgresql.conf') or SELECT pg_read_file('/etc/passwd'). Because these are syntactic SELECT statements, they pass the allowed_statement_types=['SELECT'] allowlist.
4. Bypass regex blocklist: The generated query reaches _validate_query(), which checks _DANGEROUS_SQL_PATTERNS. None of the patterns match pg_read_file, pg_stat_file, pg_ls_logdir, pg_ls_waldir, or pg_current_logfile, so the query is allowed.
5. Execute via SQLAlchemy: The query is passed to SQLChatAgent.run_query, which executes it via session.execute(text(query)) against the live database engine.
6. Exfiltrate results: The query result (file contents, metadata, or directory listings) is returned to the LLM and surfaced in the agent's response to the attacker (GitHub Advisory, Patch Commit).

• Database Logs: PostgreSQL logs showing execution of pg_read_file(), pg_stat_file(), pg_ls_logdir(), pg_ls_waldir(), pg_ls_tmpdir(), pg_ls_archive_statusdir(), or pg_current_logfile() queries originating from the langroid application DB user.
• Application Logs: LLM-generated SQL queries in langroid application logs containing the above PostgreSQL function names, especially with file path arguments like /etc/passwd, postgresql.conf, pg_hba.conf, or ~/.pgpass.
• Network: Unexpected outbound connections from the database host to remote SQL Servers or UNC paths (indicative of MSSQL OPENDATASOURCE exploitation).
• File System (SQLite deployments): New or unexpected SQLite database files attached to the application schema, or evidence of ATTACH '<path>' AS <name> statements in query logs.

Upgrade langroid to version 0.64.0, which replaces the per-name regex patterns with a family-prefix regex (\bpg_(read|stat|ls|current_logfile)[A-Za-z0-9_]*\s*\() covering the entire PostgreSQL filesystem-disclosure function family, adds OPENDATASOURCE alongside OPENROWSET, fixes the SQLite ATTACH pattern to match the optional DATABASE keyword, and extends the CREATE blocklist. The patch is available via PyPI (pip install 'langroid>=0.64.0') and the fix commit is 00b7dd7. As a defense-in-depth measure, restrict the PostgreSQL database role used by the agent to the minimum required privileges and avoid superuser roles, which limits the scope of pg_read_file() to PGDATA-relative paths only (GitHub Advisory, Patch Commit).

The vulnerability was reported by security researcher tonghuaroot and published by langroid maintainer pchalasani on May 28, 2026, with the GitHub Advisory Database entry published July 2, 2026. The advisory includes a comprehensive proof-of-concept and suggested fix, reflecting a thorough responsible disclosure process. The CVE has been picked up by automated vulnerability tracking services including VulnDB, CIRCL, and INCIBE-CERT, but no significant independent researcher commentary or media coverage has been identified beyond standard aggregator republication (GitHub Advisory).