Langroid SQLChatAgent：从提示词到 SQL 注入再到 RCE（CVE-2026-25879）

这是什么？

2026 年 6 月 1 日，针对 Langroid 发布了 CVE-2026-25879。Langroid 是一个用于构建 LLM 驱动应用的 Python 框架。该公告（GHSA-mxfr-6hcw-j9rq，于 2026 年 5 月 27 日经 GitHub 审核）将该问题评为 9.8 严重（CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H），并归类为 CWE-89（SQL 注入）与 CWE-94（代码注入）。

受影响的组件是 SQLChatAgent，这是一个内置代理，允许用户用自然语言对数据库提问。该代理请求 LLM 将问题翻译成 SQL，然后执行这段 SQL。由于 SQL 由可被提示词注入操控的模型生成，能够塑造代理输入的攻击者——无论是直接输入，还是通过代理从数据库回读的数据间接注入——都能让代理发出并执行运维方从未预期的查询。0.63.0 之前的版本均存在该漏洞。

工作原理

根本原因是一条本应存在却缺失的信任边界：模型的输出被当作特权命令执行，在生成与执行之间没有任何白名单。LLM 生成的 SQL 被直接传给数据库驱动（据公告的调用栈，即 sql_chat_agent.py 中的 run_query）：模型被诱导写出什么，数据库就会尝试执行什么。

从”普通 SQL 注入”升级为”远程代码执行”，来自数据库角色，而非 Langroid 本身。当连接使用具备代码执行或文件系统访问权限的角色时，普通的 SQL 就变成了 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)

这些原语都是早有文档记载的 DBA 功能，并非新的攻击工具。新意在于投递路径：不是通过参数化字段进行经典的 Web 注入，而是把”注入点”放在了对话式提示词里，被欺骗的对象是一个语言模型。公开的概念验证将恶意指令伪装成无害的”集成测试”，并把目标语句隐藏在一个编码步骤之后，使请求看起来只是无害的解码工作，而非显眼的命令。我们刻意不在此复现可用的有效载荷；对防御而言重要的是机制本身，而报告者的 PoC 仅通过 COPY ... FROM PROGRAM 执行 id，以证明该原语确实被触发。

这是同一框架中第三个遵循相同模式的 RCE：*代理工具针对强大的后端执行由模型控制的代码。*在此之前是 CVE-2025-46724（TableChatAgent 中的 pandas_eval 代码注入）及其 2026 年 2 月的 WAF 绕过续作 CVE-2026-25481（9.4 严重）。黑名单被绕过；SQL 变体只是把同样的问题搬到了数据库层。

为何重要

只读的”与数据库对话”功能，正是团队在没有威胁建模的情况下就上线的那类集成，因为它看上去是只读的。CVE-2026-25879 证明事实并非如此：在 AV:N/AC:L/PR:N/UI:N 之下，能够触达代理输入的未认证远程攻击者——一个客服聊天机器人、一条摄入攻击者可控文档的 RAG 流水线、一个工单助手——只要连接权限过高，就能触及数据库主机的 shell。

间接路径才是最危险的。即便最终用户可信，代理回读的任何数据都可能携带指令。一行被投毒的记录、一个伪造的 PDF、一个评论字段，或代理随后总结的一个被抓取的网页，都可能成为注入载体：攻击面变成了代理接触的整个语料，而不仅仅是聊天框。

三个 CVE 的反复出现才是真正的教训。缺陷是架构性的：只要框架允许 LLM 的输出在没有硬性关卡的情况下抵达 eval、shell 或特权 SQL 会话，修补一个工具只会让漏洞换个位置。任何构建会执行模型生成代码或查询的代理的人，都应假定自己拥有的是这一整类问题，而不仅仅是这一个 CVE。

防御

1. **升级到 Langroid 0.63.0 或更高版本。**修复将 SQLChatAgent 默认改为仅允许 SELECT 的 sqlglot 解析语句白名单，并配以方言感知的危险模式黑名单。只有当你显式设置 allow_dangerous_operations=True 时，旧行为才会恢复——除非部署完全可信，否则请保持其关闭。
2. **对数据库角色实施最小权限。**这是无论框架是否有缺陷都能打断 RCE 的控制点。为代理分配一个专用的只读角色；撤销 FILE（MySQL），使其远离 PostgreSQL 超级用户 / pg_execute_server_program，并确保 xp_cmdshell 已禁用（MSSQL）。在此 CVE 中，RCE 完全取决于角色的权限。
3. **在执行前校验生成的 SQL。**用真正的 SQL 解析器解析模型输出，仅允许预期的语句类型，拒绝 DDL/管理类动词（COPY ... FROM PROGRAM、CREATE FUNCTION、INTO OUTFILE、EXEC）。绝不要把未经解析的 LLM 文本传给驱动。
4. **隔离后端。**将数据库（以及任何代码执行工具）置于无出站访问、无可用于横向移动凭据的网络段中，使一次成功的注入落在受限的影响半径内。
5. **将摄入的数据视为不可信输入。**对 RAG 和使用工具的代理而言，间接通道最为关键：清洗并限定检索到的内容，不要让被总结的文档在没有人工关卡的情况下驱动特权操作。
6. **记录并审查工具调用。**记录每一次代理执行的确切 SQL。包含 PROGRAM、OUTFILE、xp_cmdshell 或意外 DDL 的语句是高价值告警。

状态

项目	参考	日期	备注
GHSA 公告	GHSA-mxfr-6hcw-j9rq	2026-05-27	经 GitHub 审核，SQLChatAgent 提示词到 SQL → RCE
CVE 记录发布	NVD / CVE	2026-06-01	CVSS 9.8，CWE-89 + CWE-94
受影响版本	langroid	< 0.63.0	当数据库角色允许代码/文件原语时可 RCE
修复版本	langroid	0.63.0	仅 SELECT 白名单；可通过 allow_dangerous_operations 退出
此前相关 RCE	CVE-2025-46724 / CVE-2026-25481	2025 → 2026 年 2 月	TableChatAgent 中的 pandas_eval 注入 + WAF 绕过

标题不是”某个 LLM 写了糟糕的 SQL”。而是：一个拥有特权数据库连接的对话式代理，就是一台等待合适句子的远程 shell——真正有效的修复是最小权限，加上在生成与执行之间设一道解析器，而不是更聪明的提示词。