标签 WeKnora 下的文章

漏洞概述 CVE-2026-22687是一个存在于WeKnora Agent服务中的SQL注入漏洞。该漏洞由于后端代码对用户输入的SQL语句校验不严，导致攻击者可以通过精心构造的提示词绕过安全限制，执行任意SQL查询，从而获取数据库服务器中的敏感信息。 影响范围： <0.2.4 ●所有启用Agent服务的WeKnora实例 漏洞详情 漏洞位置 文件: /internal/agent/tools/database_query.go 函数: validateAndSecureSQL() (第249-373行) API端点: POST /api/v1/agent-chat/{session_id} 漏洞根因 1.后端 安全校验逻辑缺陷 在validateAndSecureSQL函数中，开发者试图通过正则表达式检查SQL语句中涉及的表名，只允许访问预定义的白名单表： ​

Plain Text

复制代码
allowedTables := []string{
"tenants", "knowledge_bases", "knowledges", "sessions",
"messages", "chunks", "embeddings", "models",
}

// 提取FROM和JOIN子句中的表名
tablePattern := regexp.MustCompile(`(?i)\b(?:from|join)\s+([a-z_]+)(?:\s+as\s+[a-z_]+|\s+[a-z_]+)?`)
matches := tablePattern.FindAllStringSubmatch(lowerSQL, -1)

2. 两处关键绕过点 第一处漏洞：未校验PostgreSQL内置危险函数
 代码仅检查表名是否在白名单中，但完全忽略了对数据库函数的校验。攻击者可以利用PostgreSQL内置函数（如pg_ls_dir、pg_read_file等）进行文件系统操作。 第二处漏洞：未考虑SQL注释绕过
 正则表达式使用\s+匹配空白字符，但攻击者可以使用/**/等SQL注释代替空格，从而绕过表名检测： ​

Plain Text

复制代码
-- 原始查询（会被拦截）
SELECT pg_ls_dir('/etc')

-- 绕过后的查询（使用注释代替空格）
SELECT/**/pg_ls_dir('/etc')

代码分析 代码执行流 ​

Plain Text

复制代码
// 漏洞点1：原始SQL执行，无参数化查询
func (t *DatabaseQueryTool) Execute() {
// line 158: 直接执行原始SQL
t.db.WithContext(ctx).Raw(securedSQL).Rows()
}

// 漏洞点2：校验函数存在缺陷
func validateAndSecureSQL(sql string) error {
// 仅检查表名，不检查函数和存储过程
// 使用简单正则，易被注释绕过
}

1 缺少参数化查询：直接拼接用户输入执行SQL 2 函数名白名单缺失：未限制可执行的数据函数 3 SQL解析不完整：依赖简单正则而非完整SQL解析器 4 多层转义缺失：未对用户输入进行适当的转义处理 漏洞复现

​


CVE-2026-22688 - 腾讯WeKnora MCP Stdio 命令注入漏洞

前言
分析了这个漏洞，和 Cherry Studio 的 RCE 漏洞有些许类似，都是通过构造 MCP 服务器，然后传入恶意的参数导致的 RCE 漏洞，之后官方也是进行了修复


一、漏洞描述
WeKnora 是一个基于大型语言模型（LLM）的框架，专为深度文档理解和语义检索而设计，尤其适用于处理复杂、异构文档。
它采用模块化架构，结合了多模态预处理、语义向量索引、智能检索和大型语言模型推理。WeKnora 的核心遵循 RAG（检索增强生成） 范式，通过将相关文档块与模型推理相结合，实现高质量、上下文感知性的答案。
WeKnora 在 0.2.5 版本之前，当用户创建或更新 MCP 服务时，如果传输类型选择 stdio，系统直接将用户提交的 command 和 args 参数传递给 exec.Command() 执行，未进行任何安全验证。
攻击者可以通过指定任意命令（如 bash、sh）及其参数，在服务器端执行恶意系统命令。由于服务通常以容器化方式部署，攻击者可获得容器内的 shell 访问权限，进一步可能逃逸到宿主机。

二、环境搭建

我的环境
● 软件版本: WeKnora 0.2.3 (漏洞版本)

● 部署方式: Docker Compose

● 测试环境: macOS / Linux

● Go 版本: 1.24

部署步骤
​


docker compose build --build-arg GOPROXY_ARG=https://goproxy.cn,direct --build-arg APK_MIRROR_ARG= app

docker compose up -d postgres redis docreader app

验证



三、漏洞分析/代码分析

漏洞触发链路
老规矩，先看链路，先懂整体流程后，然后再去分析代码，就会方便很多了

代码分析
我们直接定位到和 MCP 相关的代码部分，一个是客户端代码，一个服务端代码

客户端代码
其实核心就是参数传递的过程中，解析问题，如果没有对我们传入的参数做任何过滤，在客户端调用的过程中直接执行
NewMCPClient 函数：

创建 MCP 服务的 API 入口
文件位置: internal/handler/mcp_service.go
完整的 CreateMCPService 函数：
核心问题都在注释中标注出来了，创建 MCP 服务端，服务端解析的时候，也没有任何验证

服务层测试逻辑
文件位置: internal/application/service/mcp_service.go
TestMCPService 函数：




命令执行的核心代码
文件位置: internal/mcp/client.go
NewMCPClient 函数中的 stdio 处理部分：

Connect 函数：

四、漏洞复现

复现步骤

步骤 1: 注册用户账号
请求：





然后我们去登录

步骤 2: 登录获取 Token
请求：





有了用户我们就可以创建 MCP 服务器了

步骤 3: 创建恶意 MCP 服务
请求：





步骤 4: 触发命令执行
请求：



这部响应会超时，是正常的





步骤 5: 验证命令执行结果



成功


一键利用脚本
文件: exploit_weknora_rce.py



五、漏洞修复
修复版本: WeKnora >= 0.2.5
官方在 commit f7900a5e9a18c99d25cec9589ead9e4e59ce04bb 中添加了完整的输入验证机制。




internal/utils/security.go



主要是四个方面加入了黑名单


参考资料
●GHSA-78h3-63c4-5fqc - WeKnora MCP Stdio Command Injection
●修复 Commit f7900a5
●WeKnora GitHub Repository
●CWE-78: OS Command Injection
●Model Context Protocol (MCP) Specification

​