开源AI工具SillyTavern现高危漏洞,内网扫描与API密钥泄漏风险需警惕

知名的开源大模型(LLM)前端交互工具 SillyTavern 被披露存在严重设计缺陷,影响 1.18.0 之前的所有版本。该漏洞主要涉及服务端请求伪造(SSRF)和敏感的 API Key 泄漏问题。安全分析显示,攻击者可以利用多个缺乏验证的 API 端点,向服务器内网地址发起恶意请求。在 `/remote/kobold/count` 端点中,用户输入的 `url` 参数未经过滤即被拼接到请求地址中,虽然响应内容被隐藏,但攻击者可通过响应时间的显著差异(端口开放瞬间返回,关闭延迟返回)来探测内网端口开放状态。更为严重的是 `/remote/textgenerationwebui/encode` 端点,代码逻辑调用了 `setAdditionalHeaders` 函数,该函数会自动将用户配置的第三方服务 API Key(如 OpenAI、Claude 等)附加到发出的 HTTP 请求头中。由于目标 URL 完全由攻击者控制,这导致存储在 SillyTavern 中的敏感密钥直接发送给攻击者搭建的恶意服务器。此外,KoboldCPP 搜索端点和 `/visit` 端点也存在类似 SSRF 漏洞,甚至可以通过 `nip.io` 等技巧绕过 IP 地址校验机制。目前官方已在后续版本中修复了部分问题,但部分端点的补丁仍不完善,建议用户尽快升级至最新版本并检查日志是否存在异常访问记录。

事件分析

此次漏洞披露揭示了 AI 生态系统中开源工具普遍存在的安全短板。SillyTavern 作为连接用户与各类 LLM 后端的流行中间层,其核心设计逻辑往往侧重于功能兼容性与接入便捷性,而在输入校验与请求隔离方面存在疏漏。对于多租户 Docker 环境或部署在内网的企业用户而言,SSRF 漏洞不仅暴露了内网拓扑,更可能被攻击者作为跳板攻击内部基础设施。特别是 API Key 的自动转发机制,将原本用于提升开发效率的功能(如自动鉴权)变成了致命的隐私泄露通道。这种“代理式”的请求转发在各类 AI Agent 和中间件工具中极为常见,此次事件为开发者敲响了警钟:在处理用户可控的 URL 参数时,必须实施严格的白名单校验和内网隔离策略,防止工具成为攻击者手中的“内网扫描器”或“密钥收割机”。

💡 核心观点:AI 代理工具在便捷性与安全性之间的失衡再次警示开发者:未经校验的请求转发是巨大的安全隐患,API 密钥管理不容忽视。

原文链接:Linux.do

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

抢沙发

评论前必须登录!

立即登录   注册