CVE-2026-50180: 
Python vulnerability analysis and mitigation

CVE-2026-50180 is a security control bypass vulnerability in the Langroid LLM application framework that enables arbitrary file read from the PostgreSQL host via SQL injection through an incomplete blocklist. The SQLChatAgent component's _validate_query defense layer uses a regex-based _DANGEROUS_SQL_PATTERNS blocklist that fails to cover the PostgreSQL filesystem-disclosure function family (pg_read_file(), pg_stat_file(), pg_ls_logdir(), pg_ls_waldir(), pg_current_logfile(), etc.), 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 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 allowlist/blocklist design (CWE-22, CWE-89) in langroid/agent/special/sql/sql_chat_agent.py at lines 113–141. The _DANGEROUS_SQL_PATTERNS list blocks specific PostgreSQL function names by exact regex match (e.g., pg_read_server_file, pg_read_binary_file, pg_ls_dir) but omits near-name siblings in the same filesystem-disclosure family. Because each omitted function (pg_read_file, pg_stat_file, pg_ls_logdir, etc.) is syntactically a SELECT-shaped call, the payloads also pass the statement-type allowlist (allowed_statement_types=['SELECT']), then reach 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 — requiring no PostgreSQL credentials of their own, as the agent holds them. A public proof-of-concept script (poc.py) demonstrates live execution of all five bypass payloads against a transient PostgreSQL instance with no external LLM provider required (GitHub Advisory, Patch Commit).

Successful exploitation allows an attacker to read arbitrary files from the PostgreSQL server host. On self-managed PostgreSQL deployments where the DB role is a superuser, absolute file paths are accepted, exposing sensitive files such as postgresql.conf, pg_hba.conf, ~/.pgpass, TLS private keys, and any file readable by the PostgreSQL OS user. Secondary impacts include filesystem reconnaissance (file existence, size, timestamps via pg_stat_file(); log and WAL directory listings), and on MSSQL deployments, OPENDATASOURCE enables outbound reads to remote SQL Servers and UNC paths, providing an intranet pivot vector. The vulnerability has no integrity or availability impact — it is a pure confidentiality breach (GitHub Advisory).

1. Identify a target: Locate a service or application built on Langroid's SQLChatAgent backed by a PostgreSQL database, running langroid <= 0.63.0.
2. Craft a prompt injection payload: Prepare a user message or embed malicious content in a data source the LLM will ingest (e.g., a document, database row, or tool result) that instructs the LLM to generate a specific SQL query.
3. Inject the bypass SQL: Cause the LLM to generate a query using an unblocked PostgreSQL file-disclosure function, for example:

   SELECT pg_read_file('postgresql.conf')

   or for reconnaissance:

   SELECT pg_ls_logdir()

4. Bypass validation: The generated query passes _validate_query because (a) none of the function names match the _DANGEROUS_SQL_PATTERNS regex blocklist, and (b) each is a syntactic SELECT, satisfying the allowed_statement_types=['SELECT'] allowlist.
5. Achieve file read: The query reaches SQLChatAgent.run_query → SQLAlchemy session.execute(text(query)), which executes against the live PostgreSQL instance using the agent's credentials. The file contents are returned as query results and fed back into the LLM conversation history, where the attacker can read them (GitHub Advisory, Patch Commit).

• Database Logs: PostgreSQL query logs (log_statement = 'all') showing SELECT pg_read_file(...), SELECT pg_stat_file(...), SELECT pg_ls_logdir(), SELECT pg_ls_waldir(), SELECT pg_ls_tmpdir(), SELECT pg_ls_archive_statusdir(), or SELECT pg_current_logfile() queries originating from the application's DB role.
• Application Logs: Langroid/SQLChatAgent application logs showing LLM-generated SQL containing the above function calls being passed to run_query; unexpected query results containing file path strings, configuration content, or directory listings returned to the LLM.
• Network: On MSSQL deployments, unexpected outbound connections from the database server to remote hosts or UNC paths triggered by OPENDATASOURCE queries.
• File System: Evidence of sensitive file access (e.g., postgresql.conf, pg_hba.conf, TLS key files) reflected in query result logs or LLM conversation history exports (GitHub Advisory).

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*\( that covers 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. No configuration-based workaround is available for the default deployment; the only remediation is upgrading to 0.64.0. As an additional defense-in-depth measure, restrict the PostgreSQL role used by the agent to the minimum required privileges and avoid superuser roles (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 CVE was noted in automated CVE tracking feeds including Bluesky CVE bot posts and INCIBE-CERT early warning alerts. No significant broader media coverage or notable researcher commentary beyond the advisory itself has been identified.