AUGUST 24, 2026
Live Feed
Back to database
Case File

CVE-2026-50180

HIGH · CVSS 8.7 EPSS 0.57% Public Exploit

Source: NVD + CISA KEV + EPSS · Published 2026-07-10 · Last synced 2026-08-09

CyberRota Analysis

AI-Generated

The Langroid framework, specifically the `SQLChatAgent` component, is vulnerable to SQL injection attacks due to an incomplete regex blocklist that fails to account for certain dangerous PostgreSQL functions, as well as SQL Server and SQLite commands. This oversight allows an attacker to execute arbitrary file read operations on the PostgreSQL host through crafted SQL queries, even when strict configurations are applied. Organizations using versions prior to 0.64.0 should prioritize updating to the patched version to mitigate the risk of unauthorized data exposure.

Public Exploit Signal

A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.

Note: these links are listed for security research and verification purposes only.

CVE
CVE-2026-50180
Severity
HIGH
CVSS
8.7
EPSS
0.57%

Original NVD Description

Langroid is a framework for building large-language-model-powered applications. Prior to version 0.64.0, `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`. Version 0.64.0 contains a patch for the issue.