Langroid SQLChatAgent: prompt-to-SQL injection escalates to RCE (CVE-2026-25879)

What is this?

On June 1, 2026, CVE-2026-25879 was published for Langroid, a Python framework for building LLM-powered applications. The advisory (GHSA-mxfr-6hcw-j9rq, reviewed by GitHub on May 27, 2026) rates the issue 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and tags it CWE-89 (SQL injection) and CWE-94 (code injection).

The affected component is SQLChatAgent, a built-in agent that lets users ask natural-language questions about a database. The agent asks an LLM to translate the question into SQL and then executes that SQL. Because the SQL is produced by a model that can be steered through prompt injection, an attacker who can shape the agent’s input — directly, or indirectly through data the agent reads back from the database — can get the agent to emit and run statements the operator never intended. Versions before 0.63.0 are vulnerable.

How it works

The root cause is a trust boundary that does not exist: the model’s output is executed as a privileged command with no allowlist between generation and execution. SQL generated by the LLM flows straight to the database driver (run_query in sql_chat_agent.py, per the advisory’s call trace), so whatever the model can be convinced to write, the database will try to run.

The escalation from “SQL injection” to “remote code execution” comes from the database role, not from Langroid itself. When the connection uses a role with code-execution or filesystem privileges, ordinary SQL becomes a shell:

PostgreSQL : COPY ... FROM PROGRAM '<command>'   (needs pg_execute_server_program / superuser)
MySQL      : SELECT ... INTO OUTFILE / LOAD_FILE  (needs FILE privilege)
MSSQL      : EXEC xp_cmdshell '<command>'         (needs xp_cmdshell enabled)

These primitives are long-documented DBA features, not new attack tooling. The novelty is the delivery path: instead of a classic web injection through a parameterized field, the “injection point” is a conversational prompt, and the thing being tricked is a language model. The public proof of concept frames a malicious instruction as a benign-sounding “integration test” and hides the target statement behind an encoding step so the request reads as harmless decoding work rather than an obvious command. We are deliberately not reproducing the working payload here; the mechanism is what matters defensively, and the reporter’s PoC executes id via COPY ... FROM PROGRAM only to prove the primitive fires.

This is the third RCE in the same framework to follow one shape — an agent tool executes model-controlled code against a powerful backend. It was preceded by CVE-2025-46724 (pandas_eval code injection in TableChatAgent) and its February 2026 WAF-bypass follow-up CVE-2026-25481 (9.4 Critical). Blocklists were bypassed; the SQL variant simply moved the same problem to the database layer.

Why it matters

A read-only “chat with your database” feature is exactly the kind of integration teams ship without a threat model, because it feels read-only. CVE-2026-25879 shows it is not: with AV:N/AC:L/PR:N/UI:N, an unauthenticated remote actor who can reach the agent’s input — a support chatbot, a RAG pipeline that ingests attacker-controlled documents, a ticketing assistant — can reach the database host’s shell if the connection is over-privileged.

The indirect path is the dangerous one. Even when end users are trusted, any data the agent reads can carry instructions. A poisoned row, a crafted PDF, a comment field, or a scraped web page that the agent later summarizes can all become the injection vector, which means the attack surface is the entire corpus the agent touches, not just the chat box.

The recurrence across three CVEs is the real lesson. The defect is architectural: as long as a framework lets an LLM’s output reach an eval, a shell, or a privileged SQL session without a hard gate, patching one tool just relocates the bug. Anyone building agents that execute model-generated code or queries should assume they own this class of problem, not just this CVE.

Defenses

1. Upgrade to Langroid 0.63.0 or later. The fix defaults SQLChatAgent to a SELECT-only, sqlglot-parsed statement allowlist with a dialect-aware dangerous-pattern blocklist. The legacy behavior only returns if you explicitly set allow_dangerous_operations=True — leave it off unless the deployment is fully trusted.
2. Least-privilege the database role. This is the control that breaks the RCE regardless of framework bugs. Give the agent a dedicated read-only role; revoke FILE (MySQL), keep it off PostgreSQL superuser / pg_execute_server_program, and ensure xp_cmdshell is disabled (MSSQL). RCE in this CVE depends entirely on the role’s privileges.
3. Validate generated SQL before execution. Parse model output with a real SQL parser, allow only intended statement types, and reject DDL/administrative verbs (COPY ... FROM PROGRAM, CREATE FUNCTION, INTO OUTFILE, EXEC). Never pass LLM text to a driver unparsed.
4. Isolate the backend. Run the database (and any code-execution tool) in a network segment with no outbound access and no credentials to pivot with, so a successful injection lands in a contained blast radius.
5. Treat ingested data as untrusted input. For RAG and tool-using agents, the indirect channel matters most: sanitize and bound retrieved content, and don’t let summarized documents drive privileged actions without a human gate.
6. Log and review tool calls. Record the exact SQL each agent run executes. Statements containing PROGRAM, OUTFILE, xp_cmdshell, or unexpected DDL are high-signal alerts.

Status

Item	Reference	Date	Notes
GHSA advisory	GHSA-mxfr-6hcw-j9rq	2026-05-27	GitHub-reviewed, SQLChatAgent prompt-to-SQL → RCE
CVE record published	NVD / CVE	2026-06-01	CVSS 9.8, CWE-89 + CWE-94
Affected versions	langroid	< 0.63.0	RCE when DB role allows code/file primitives
Fixed version	langroid	0.63.0	SELECT-only allowlist; allow_dangerous_operations opt-out
Prior related RCE	CVE-2025-46724 / CVE-2026-25481	2025 → Feb 2026	pandas_eval injection + WAF bypass in TableChatAgent

The headline is not “an LLM wrote bad SQL.” It is that a conversational agent with a privileged database connection is a remote shell waiting for the right sentence — and the fix that holds is least privilege plus a parser between generation and execution, not a smarter prompt.