研究者披露 LiteLLM 网关跨租户干扰攻击 Cooldown Landmines

LLM 网关中共享的冷却（cooldown）状态可被攻击者利用引发跨租户干扰攻击。

• 场景与重要性：LLM 网关（如 LiteLLM）通常允许多个租户使用独立认证密钥与用量配额，同时共享底层的模型部署（deployments）。为了提升可靠性，网关会共享部署故障记录并在触发后进入冷却期，避免后续请求重复打向故障节点。

• 现有机制的缺陷：网关的请求准入控制与后端故障处理解耦。租户自身配额超限触发的拒绝，可能被错误地计入后端部署的故障记录；此外，瞬时配额耗尽导致的后端冷却记录在容量恢复后仍会残留。

• 核心观察与假设：作者观察到，冷却记录具有独立于实际容量恢复的持续时间，且网关缺乏对故障源头的严格归属性校验。攻击者可利用这一状态依赖性，阻断其他合法租户对可用后端的访问。

• 提出的主要内容：作者识别出利用本地准入拒绝与放行流量残留冷却的两类攻击路径，并设计了来源检查标记与按租户作用域隔离 429 冷却记录的防御机制。

• 威胁模型：

  • 攻击者目标：将可用后端排除在受害租户的路由之外，迫使受害者遭遇服务拒绝（denial）、非合规降级回退（fallback）或篡改下游投票聚合决策。
  • 攻击者知识：攻击者持有普通有效租户密钥，不掌握受害者凭证，无法更改网关配置，无法直接写入冷却缓存；在本地拒绝攻击中假设攻击者知晓目标注册部署 ID。
  • 攻击者能力：控制自身请求的发送时机与内容，Prompt 保持良性，受限于或显式受限于自身配额预算。
  • 受害系统：受害租户 B 与攻击者 A 共享至少一个模型部署及冷却缓存，B 的请求均符合其自身认证与配额限制。

租户隔离与故障处理机制

• 资源隔离与流控：AWS（2020）探讨多租户环境中的资源隔离；Popa 等人（2012）在 FairCloud 中研究网络带宽分配。RFC 8084（Fairhurst, 2017）规范了网络传输熔断机制中对反馈真实性与完整性的保护；AWS（n.d.）的自适应限流器在客户端内共享限流反馈。作者指出本文防御将故障来源与继承冷却的租户显式解耦。

路由攻击与缓存投毒

• 模型路由安全性：RouteLLM（Ong 等人, 2025）研究基于偏好数据的模型路由；Shafran 等人（2025）、Lin 等人（2025）、Tang 等人（2026）研究对 LLM 路由器的对抗输入操纵，RerouteGuard（Zhang 等人, 2026）提出防御。作者指出本文研究的是部署可用性（deployment eligibility），而非内容驱动的模型选择。
• 缓存安全与拒绝服务：CPDoS（Nguyen 等人, 2019）研究攻击者诱导错误响应并缓存在 CDN 中导致拒绝服务；PROMPTPEEK（Wu 等人, 2025）与 KVGov（Addagada, 2026）研究多租户推理中 KV cache 的隐私泄露与隔离。作者指出本文关注的是网关层冷却状态对后续租户路由的影响。

持久性与服务影响

• 状态转移与回退异常：ContinuityBench（Pandey & Singh, 2026）报告多提供商路由中有状态故障转移的竞争与重试限流；Shrew（Kuzmanovic & Knightly, 2003）研究低速率拒绝服务攻击；Bronson 等人（2021）与 Huang 等人（2022）分析分布式系统中的亚稳态故障。ComplianceGate（Dey, 2026）研究规管环境下的分类分层路由。

对比基线与基准

• 论文对比了未修改的原生 LiteLLM v1.99.0（Stock Cooldown）、完全禁用冷却（Disabled Cooldown）、跳过 429 冷却（Skip 429 Cooldown）以及缩短冷却时间（Short Cooldown）。此外在扩展评估中考察了 AWS 示例配置（LiteLLM 1.89.1）、Kong 3.6 与 Portkey。
• 作者将本文工作定位为指出 LLM 网关在请求准入与后端共享可用性处理之间缺乏租户隔离，并提出了兼顾故障隔离与背压的缓解方案。

针对共享冷却状态的缺陷，作者提出了来源检查标记与按租户作用域隔离两项缓解机制。

问题设定与形式化

设 D 为部署集合，C(d) 为部署 d ∈ D 的共享冷却记录。在原生处理中，攻击者通过伪造包含目标部署 ID 的元数据触发本地 429 异常，上游调用数满足：

使得未经上游调用的部署进入冷却。对于放行流量，配额清空时刻 τ_clear(d) 与冷却到期时刻 τ_expire(d) 独立，在时间区间 I_d = [τ_clear(d), τ_expire(d)) 内引发残留排除。受害者可用路由集缩减为：

其中 H_B(τ) 为满足合规条件的健康部署，K(τ) 为处于活跃冷却状态的部署。当 H_B(τ) ⊆ K(τ) 时，R_B(τ) = ∅，引发彻底拒绝服务或跨区域回退违规。

阻断本地配额拒绝的部署更新（M1 Origin Check）

• 服务端异常标记：网关在生成失败元数据前，为因租户 API Key RPM 超限引发的异常附加服务端枚举标记。
• 对象标识校验：网关在多处回调中通过对象标识（object identity）检查该标记，客户端无法通过请求体伪造。
• 守卫状态更新：若异常带有标记，状态更新直接保持原状，阻止其更新部署失败计数器、RPM 统计和冷却记录；未标记的异常仍执行原状态更新逻辑。

按认证租户隔离 HTTP 429 冷却（M2 Tenant Scoping）

• 租户记录与全局记录解耦：将冷却记录分为全局故障记录 G(d) 与租户特定记录 Q(d, t)。当错误状态码为 429 时，仅更新触发租户的 Q(d, t)；非 429 错误（如 5xx 故障）则写入全局记录 G(d)。
• 联合状态读取：路由检查部署是否被排除时，计算 C_t(d, τ) = live(G(d), τ) ∨ live(Q(d, t), τ)，取二者中较晚的到期时间作为排除依据。
• 保留独立重试与背压：该设计使攻击者 A 维持背压回退，同时保证 C_B⁺(d, τ) = C_B(d, τ)（对任意 A ≠ B），允许其他租户独立尝试使用已恢复的后端容量。

身份传递与缓存实现

• 租户身份提取：认证钩子从请求上下文中按优先级提取注册密钥别名（key_alias）、user_id 或默认命名空间 GLOBAL，并通过 Python ContextVar 在异步流程中传递。
• 缓存键设计与批量读取：租户记录键包含部署 ID 与租户 ID，全局记录仅包含部署 ID。异步实现将一次候选查询中的两个键进行批量读取，避免跨租户状态混淆。

实验设置

• 被测系统与模型：LiteLLM v1.99.0（Python Router 与 HTTP 代理）、Kong 3.6；真实推理模型使用 Qwen1.5-MoE-A2.7B-Chat 和 DeepSeek-MoE-16B-Chat（均部署于 vLLM 0.28.0，运行于 2 台 NVIDIA H800 GPU）。
• 评测环境与存储：OpenAI API 可控配额模拟后端、PostgreSQL 存储密钥、Redis 共享 4 个 worker 的冷却状态、Apple M4 macOS（16 GiB 内存）主机测试。
• 基线方法：原生 LiteLLM v1.99.0（Stock）、完全禁用冷却（Disabled）、跳过 429 冷却（Skip 429）、1 秒超短冷却（Short）。
• 主要指标：受害者回退次数、拒绝服务次数、直接探测状态码（HTTP 200/429/500/503）、上游后端 HTTP POST 请求数、Healthy 请求延迟（p50/p99）、Redis 内存占用。
• 评测方式与样本量：状态码与日志比对、多进程日志事件校验；主要对比实验采用 5 次配对重复运行（每次运行 12 或 8 个探测请求），多租户测试包含 4、16、64 租户。

主结果

下表展示在 4 个 worker、5 次独立配对运行中，后端容量恢复后受害者请求被重定向到回退部署的次数（每轮 12 次请求，总计 60 次请求）：

表格较宽，可左右滑动

• 作者指出，在原生 LiteLLM 中，跨 worker 共享的 Redis 冷却记录使 54/60 的受害者请求在后端容量恢复后仍被错误降级到回退部署。
• 作者指出，采用租户作用域隔离（Tenant scoped）后，受害者在 5 轮测试中的 60 次请求全部成功路由至已恢复的主部署（0/60 回退）。
• 作者称在原生配置下，由于 DualCache 强制的 10 秒批量重新读取间隔，各 worker 读取 Redis 的时机差异导致了主从路由交替现象（附录 B.7）。

攻击影响与恢复排除验证

• 本地拒绝攻击与来源检查：原生 LiteLLM 下，2 个携带注册部署 ID 的本地被拒请求（0 次上游调用）直接将受害者路由从 Primary 迫使至 Fallback；引入来源检查后受害者保持在 Primary（Table 1）。
• 真实推理与投票篡改：在 DeepSeek-MoE-16B-Chat 的 5 节点多智能体投票任务中，攻击者通过伪造 ID 的本地被拒请求封锁其余 4 个节点（0 上游请求），将全部 8/8 个非 A 多数决策篡改为 A，5/5 个原本正确的决策全部变更为错误；在 3/5 仲裁机制下产生 9/9 弃权（Table 7）。
• 合规策略违规：在区域策略测试中，冷却所有合规节点后，启用回退导致 20/20 跨区域策略违规，禁用回退导致 20/20 拒绝服务（Table 6）。

运行成本与开销分析

• 上游重试负载：在 64 租户并发 429 场景下，租户隔离使上游请求中位数从 15 增至 209 次（Table 12），恢复了 40/40 的受害者探测（原生为 0/40）。
• 健康请求延迟：在 16 租户并发下，中位延迟 p50 从 19.35 ms 增至 25.10 ms（Table 13）。
• Redis 内存开销：在 2 个部署和 300 秒 TTL 下，1024 个租户保留 2048 个条目，占用内存 368 KiB（原生为 2 个条目占用 368 bytes，Fig. 4d）。

其他消融与分析

• 在 5 秒冷却下平均拒绝/攻击时间放大倍数为 12×，40 秒冷却下升至 98×（§6.2, Fig. 3c）。
• 在 13 秒和 25 秒间隔的周期脉冲下，攻击者以 1.5%–4% 占空比在 90 秒内分别造成 137/212 和 148/219 的受害者探测拒绝（Fig. 7）。
• 在连续过载调度下，租户隔离的拒绝率为 61%，原生 LiteLLM 为 67%（附录 B.9）。
• 在 4 租户 500 真实故障恢复后探测中，原生 LiteLLM 成功响应 35/40 次，租户隔离仅响应 13/40 次，作者称其具体原因尚未查明（§6.4, Table 12）。

作者指出的局限与后续方向

• 部署 ID 发现成本未测量：本地拒绝攻击依赖攻击者获知已注册的目标部署 ID，尽管响应头可能泄露 ID，但作者指出目标发现及其准备成本在论文中未作测量（§3.2、附录 A.3）。
• 生产环境特性有待进一步研究：作者指出评测中使用的顺序恢复与模拟并发负载不同于实际生产，未来需要在生产环境中研究持续干扰、精确的跨 worker RPM 核算、提供商配额归属、动态凭据、补丁传播以及并发重试（§6.6）。
• 配额归属缺乏信任映射：HTTP 429 本身无法标识配额的所有者，协调背压需要从租户到提供商配额所有者的可信映射机制，论文提出的策略只能统一按租户进行作用域隔离（§5.2）。
• 真实故障恢复存在未解差异：在 4 租户 500 错误测试中，租户隔离在恢复后仅服务了 13/40 次探测（原生为 35/40），作者明确指出该恢复差异的具体原因尚未查明（§6.4、附录 B.10）。

实验覆盖范围

• 被测系统版本：主要实验基于 LiteLLM v1.99.0，配置分析包含 AWS 示例中的 LiteLLM 1.89.1，拓展网关测试了 Kong 3.6；论文指出 Portkey 的目标合规策略执行未作验证（§6.5、附录 C.3）。
• 测试模型：真实推理实验使用了 Qwen1.5-MoE-A2.7B-Chat 与 DeepSeek-MoE-16B-Chat，各部署于 2 台 NVIDIA H800 GPU。
• 并发与规模限制：多租户并发测试覆盖 4、16、64 个租户，Redis 内存测试推演至 1024 个租户；多 worker 代理测试固定为 4 个 worker。
• 未报告信息：论文未报告攻击者在实际黑盒网关中盲测发现内部注册部署 ID 的耗时与成功率。

• 论文定位：论文研究了多租户 LLM 网关中由于共享后端故障与冷却状态导致的跨租户干扰攻击与拒绝服务风险。
• 核心问题：LLM 网关在执行独立租户配额时共享后端部署的冷却记录，导致一个租户的请求失败会污染共享状态，使正常租户被误排除在健康部署之外。
• 方法设计：揭示了本地 API Key RPM 拒绝与放行流量残留冷却两类攻击路径；提出了在网关内部给 Key 异常打标以阻断部署状态更新的 Origin Check，以及将 429 冷却记录按租户隔离的 Tenant Scoping 防御。
• 关键结果：在 4 个 worker 的 5 轮配对实验中，租户隔离将恢复后的受害者回退次数从 54/60 降低至 0/60（Table 2）；在多智能体投票任务中，攻击者通过 0 上游调用的本地拒绝将 8/8 个多数决策篡改为己方结果（Table 7）；在 64 租户并发 429 故障下，租户隔离使上游请求中位数从 15 增至 209 次（Table 12）。
• 结论与启示：作者认为网关的租户隔离设计不能仅停留在请求准入与配额层，必须同时覆盖管理后端可用性的故障处理与冷却状态。