文章总结： 文档分析了腾讯WeKnora框架CVE-2026-30860漏洞，因SQL校验遗漏ArrayExpr等节点导致注入绕过。攻击者可构造恶意SQL读取文件并利用大对象机制实现远程代码执行。建议立即升级至v0.2.12版本，并采取关闭公开注册、限制数据库权限等缓解措施，强调AI应用需建立纵深防御体系。 综合评分： 92 文章分类： 漏洞分析,AI安全,漏洞预警,解决方案
CVE-2026-30860：腾讯开源 AI 框架 WeKnora SQL 注入绕过导致远程代码执行
原创
CVE-SEC CVE-SEC
CVE-SEC
2026年3月9日 14:00 四川
CVE-2026-30860：腾讯开源 AI 框架 WeKnora SQL 注入绕过导致远程代码执行
漏洞概述
2026 年 3 月 7 日，GitHub Security 发布安全公告（GHSA-8w32-6mrw-q5wv），披露腾讯开源 RAG 框架 WeKnora 存在严重的远程代码执行漏洞，编号 CVE-2026-30860，CVSS v3.1 评分 9.9（Critical）。
该漏洞位于 WeKnora Agent 模式下的 AI 数据库查询工具中。攻击者仅需持有一个普通用户账户（而 WeKnora 默认允许任意人员自助注册），即可通过构造特制的 SQL 查询，绕过系统内置的全部七个安全校验阶段，在底层 PostgreSQL 数据库服务器上执行任意代码，进而读取服务器文件、控制数据库、植入后门并向内网横向渗透。
受影响版本
| 软件包 | 受影响版本 | 修复版本 | | — | — | — | | github.com/Tencent/WeKnora | < 0.2.12（所有版本） | v0.2.12 |
WeKnora 是腾讯面向企业知识库场景的开源框架，同时承担微信对话开放平台的核心技术职责，在国内企业私有化部署中有一定使用量。
背景知识
理解这个漏洞，需要先了解两个概念。
WeKnora 的 AI 数据库查询工具
WeKnora 的 Agent 模式允许大语言模型（LLM）通过内置工具直接与后端 PostgreSQL 数据库交互：用户用自然语言提问，LLM 将其转化为 SQL 查询并执行，再将结果整理为可读的答案返回。
这是典型的 Text-to-SQL 架构，在 AI 应用中越来越普遍，但其安全边界的维护完全依赖于中间的 SQL 校验层。
PostgreSQL 抽象语法树（AST）
SQL 语句在送入数据库执行前，会被解析器转化为一棵抽象语法树，每个语法元素对应树上的一个节点。WeKnora 的防护机制正是通过遍历这棵树、检查每个节点是否包含危险操作来实现 SQL 注入防护的。
漏洞根因
WeKnora 在 internal/utils/inject.go 中实现了一套七阶段 SQL 校验框架，其核心是第五阶段的 validateNode() 函数，负责递归遍历 SQL 的 AST，逐一检查节点是否包含被禁止的 PostgreSQL 危险函数（如 pg_read_file、lo_from_bytea、lo_export 等）。
七个校验阶段依次为：空字节检测、AST 解析、单语句限制、仅允许 SELECT、深度节点遍历、表名白名单、正则关键字兜底过滤。理论上，七道关卡串联执行，危险查询不应通过。
然而 validateNode() 在实现时遗漏了两种 AST 节点类型的处理器：
ArrayExpr：PostgreSQL 数组字面量，形如ARRAY[expr1, expr2, ...]RowExpr：行构造器，形如ROW(expr1, expr2, ...)
当函数遍历到这两种节点时，由于没有对应的处理逻辑，它直接跳过该节点及其所有子节点，不做任何检查。
这意味着：只需将危险函数调用套进 ARRAY[...] 里，就能让它对第五阶段的校验完全隐形。正则兜底（第七阶段）在部分构造方式下同样无法覆盖嵌套表达式中的函数调用。
漏洞触发条件
触发该漏洞需同时满足以下条件：
- WeKnora 版本低于 0.2.12
- Agent 功能已启用，且 AI Database Query Tool 在工具列表中处于加载状态
- 攻击者持有任意用户账户（WeKnora 默认开放注册，无需预先持有账户）
符合以上条件的实例，即处于完整攻击面之下。
攻击流程
攻击分三个阶段推进，全程通过 WeKnora 的正常 API 接口发起，无需直接访问数据库端口。
第一阶段：绕过校验，读取任意文件
在 Agent 对话中调用 AI Database Query Tool，提交以下查询：
SELECT name, ARRAY[pg_read_file('/etc/passwd'), 'filler'] FROM knowledge_bases LIMIT 1
pg_read_file() 被嵌套在 ARRAY[] 内，七阶段校验全部通过，查询提交至 PostgreSQL 执行，服务端响应中包含 /etc/passwd 的文件内容。攻击者可替换路径，读取 .env、私钥文件、数据库连接配置等任意敏感内容。
第二阶段：写入恶意共享库
在数据库用户权限足够的情况下（默认部署中 WeKnora 使用的数据库账户权限较高），可进一步利用 PostgreSQL 大对象（Large Object）机制将任意二进制文件写入服务器文件系统。
大对象操作链涉及三个函数：lo_from_bytea（在内存中创建大对象）、lo_export（将大对象内容导出至服务器磁盘）。将编译好的恶意共享库二进制数据通过该链路落盘至 /tmp/evil.so，同样通过将函数调用嵌套在 ARRAY[] 内绕过校验。
第三阶段：加载共享库，执行任意命令
CREATE FUNCTION exec_cmd(text) RETURNS text AS '/tmp/evil.so', 'exec_cmd' LANGUAGE C STRICT;
SELECT exec_cmd('id');
至此，攻击者以数据库用户权限在服务器上实现任意命令执行。后续可建立持久化后门、读取内存中的凭据、或以数据库服务器为跳板渗透内网其他系统。
修复方案
官方修复（推荐）
升级至 WeKnora v0.2.12。
cd /path/to/WeKnora
git fetch origin
git checkout tags/v0.2.12
docker compose build
docker compose up -d
v0.2.12 在 validateNode() 中补充了 ArrayExpr 和 RowExpr 两种节点的处理器，对这两类节点的子节点同样执行完整的递归校验，同时新增了 internal/utils/blocklist.go 模块，集中维护危险 PostgreSQL 函数的黑名单。
临时缓解措施
若暂时无法升级，可采取以下措施降低风险：
- 关闭 WeKnora 公开注册入口，禁止陌生用户自行创建账户；
- 通过防火墙限制 WeKnora 服务仅对内网可信 IP 段开放，禁止公网直接访问；
- 将 WeKnora 所使用的 PostgreSQL 数据库账户权限降至最低，仅授予必要的 SELECT 权限，明确撤销大对象操作函数的执行权限；
- 在 WAF 中添加规则，拦截请求体中包含
pg_read_file、lo_from_bytea、lo_export等函数名的请求。
检测方法
流量特征
检测发往 WeKnora Agent 接口（/api/v1/chat、/api/v1/agent 等路径）的 POST 请求体，若请求体中同时出现 ARRAY[ 或 ROW( 结构，以及 pg_read_file、lo_from_bytea、lo_export、lo_import、pg_reload_conf 等关键字，判定为疑似漏洞利用尝试。
PostgreSQL 日志排查
启用 PostgreSQL 完整查询日志后，检索以下关键字：
pg_read_file
lo_from_bytea
lo_export
lo_import
pg_reload_conf
重点关注由 WeKnora 应用账户（非 DBA 账户）发起的包含上述函数的查询记录，以及 pg_largeobject 表的异常写入操作。
版本核查
在部署了 WeKnora 的环境中执行：
docker exec weknora-app cat /app/version.txt
若版本低于 0.2.12，立即安排升级。
漏洞的本质
这个漏洞揭示了 AI Agent 安全设计中一个值得关注的结构性问题。
在传统 Web 应用中，SQL 注入通常发生在用户输入直接拼接进 SQL 语句的场景。WeKnora 的防护团队显然意识到了这一风险，并投入资源构建了七阶段的 AST 级校验框架——从字节检查、语法解析、语句类型限制，到逐节点递归遍历，设计思路是完整的。
问题出在实现层面的一个遗漏：PostgreSQL AST 拥有数十种节点类型，而 validateNode() 的处理器列表并未覆盖全部。这类遗漏在手动编写遍历逻辑时并不罕见，但在安全敏感的代码路径上，任何遗漏都可能成为完整的攻击入口。
更深层的问题是：允许 LLM 或用户提交任意 SQL 并执行，本身就是一种高风险架构选择。无论校验层设计得多么严密，基于黑名单的防护总是在与攻击者的知识边界赛跑。从安全设计角度，更稳固的方案是将 AI 数据库查询限制为预定义的查询模板，而非允许任意 SQL 的执行。
对于使用 WeKnora 或类似 Text-to-SQL 框架的团队，这次事件提示了一个重要原则：不要将安全完全委托给框架内部的校验层，而应在数据库账户权限、网络隔离、操作审计等多个维度建立纵深防御。
时间线
| 时间 | 事件 | | — | — | | 2026-03-05 | CVE-2026-30860 编号预留 | | 2026-03-07 | GitHub Security Advisory GHSA-8w32-6mrw-q5wv 发布，漏洞公开披露 | | 2026-03-07 | WeKnora v0.2.12 修复版本同步发布 | | 2026-03-07 | NVD、GitLab Advisory、THREATINT 等平台同步收录 |
参考资料
- GitHub Security Advisory：https://github.com/Tencent/WeKnora/security/advisories/GHSA-8w32-6mrw-q5wv
- NVD：https://nvd.nist.gov/vuln/detail/CVE-2026-30860
- GitLab Advisory：https://advisories.gitlab.com/pkg/golang/github.com/tencent/weknora/CVE-2026-30860/
- WeKnora 官方仓库：https://github.com/Tencent/WeKnora
- TheHackerWire 技术分析：https://www.thehackerwire.com/weknora-critical-rce-in-database-query-functionality/
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：CVE-SEC CVE-SEC CVE-SEC《CVE-2026-30860：腾讯开源 AI 框架 WeKnora SQL 注入绕过导致远程代码执行》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论