CVE-2026-54760
Summary
by MITRE • 07/10/2026
Langroid is a framework for building large-language-model-powered applications. Prior to version 0.65.1, the `SQLChatAgent` SQL-injection mitigation, with default `allow_dangerous_operations=False`, combines a raw-text regex blocklist (`_DANGEROUS_SQL_PATTERNS`) with a `sqlglot` SELECT-only statement allowlist. The blocklist entries that target callable functions require the function name to be immediately followed by `\s*\(`. PostgreSQL accepts the same call with the name separated from `(` by a quoted identifier, an inline comment, or schema qualification. These forms evade the regex, still parse as `SELECT`, and execute the same PostgreSQL function. This restores the `pg_read_file` server-side file-read primitive that the prior CVE-2026-25879 / GHSA-pmch-g965-grmr fix was meant to block: the parent advisory fixed a missing `pg_read_file` blocklist entry, while this report shows that the added regex is bypassable. Version 0.65.1 fixes the issue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/10/2026
The Langroid framework presents a critical security vulnerability in its SQLChatAgent component that demonstrates the fragility of regex-based security controls when dealing with complex database query parsers. This vulnerability affects versions prior to 0.65.1 and specifically targets the SQL injection mitigation mechanisms designed to prevent dangerous operations within the framework's large language model-powered applications. The security implementation relies on a dual-layer approach combining a raw-text regex blocklist with a sqlglot-based SELECT-only statement allowlist, creating what appears to be a robust defense mechanism against malicious SQL operations.
The technical flaw stems from an insufficient understanding of PostgreSQL's query parsing behavior and how it handles function calls in SELECT statements. The original `_DANGEROUS_SQL_PATTERNS` regex blocklist specifically targets callable functions by requiring function names to be immediately followed by `\s*\(`, a pattern that works for standard SQL syntax but fails when PostgreSQL encounters alternative valid syntax forms. PostgreSQL's flexibility allows function calls where the function name can be separated from the opening parenthesis by quoted identifiers, inline comments, or schema qualification, all of which bypass the regex validation while still producing valid SELECT statements that execute the targeted dangerous functions.
This vulnerability directly impacts the security controls implemented in CVE-2026-25879 / GHSA-pmch-g965-grmr, which had previously addressed a missing `pg_read_file` blocklist entry. The subsequent fix in version 0.65.1 demonstrates that while the initial remediation attempted to address the core issue, it failed to account for all valid PostgreSQL syntax variations that could bypass the regex validation. The evasion technique exploits PostgreSQL's permissive parsing rules where `pg_read_file` can be invoked through forms like `SELECT pg_read_file('filename')` but also through `SELECT "pg_read_file"('filename')` or `SELECT pg_read_file / comment / ('filename')`, all of which parse correctly as SELECT statements yet bypass the regex pattern matching.
The operational impact of this vulnerability extends beyond simple data access, as it restores server-side file-read capabilities that could potentially allow attackers to read arbitrary files from the database server's filesystem. This represents a significant escalation from typical SQL injection attacks and aligns with common attack patterns found in the MITRE ATT&CK framework under the Database Operations category, specifically targeting the privilege escalation and data exfiltration techniques. The vulnerability demonstrates how seemingly comprehensive security controls can be undermined by incomplete understanding of underlying parser behaviors and syntax variations.
The fix implemented in version 0.65.1 addresses this by strengthening the validation mechanism to properly account for all valid PostgreSQL function call syntax variations, ensuring that dangerous functions like `pg_read_file` are blocked regardless of how they appear in SELECT statements. This represents a more comprehensive approach to SQL injection prevention that moves beyond simple regex matching toward more robust query parsing and validation techniques. The vulnerability serves as a cautionary example of why security controls must account for the full spectrum of valid syntax variations supported by target systems, particularly when dealing with database engines that offer multiple valid ways to express the same operations.
This issue highlights the importance of considering parser flexibility in security implementations and relates to CWE-89 SQL Injection vulnerabilities where improper input validation allows execution of malicious SQL code. The bypass demonstrates that regex-based controls alone are insufficient against complex parsing environments, as they cannot account for all syntactic variations that produce equivalent semantic outcomes. Organizations implementing similar security controls should consider the broader implications of their validation approaches and ensure that defensive mechanisms account for the full range of valid syntax supported by target systems rather than relying solely on pattern matching techniques that may be easily circumvented by understanding of underlying parsing behaviors.