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

部署步骤

​

验证

三、漏洞分析/代码分析

漏洞触发链路

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

代码分析

我们直接定位到和 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