PyPI 上被入侵的 LiteLLM 1.107.0 安装了凭证窃取器和后门

总体背景与事件频率

• 评论者指出同一周内发生了一连串重大安全事件（云服务中断、CA 密钥泄露、重大数据库泄露、PHP CVE、Node.js RCE），并将这次 LiteLLM 失陷视为更广泛且持续恶化的供应链问题的一部分。
• 一些人认为，这已经是 LiteLLM 在一年内第二次甚至第三次严重相关事件，并称其声誉受损。

失陷的性质与原因

• 恶意的 PyPI LiteLLM 1.107.0 wheel 包含了凭证窃取器和后门。
• 讨论认为，入侵发生在私有构建/发布流水线中，而不是公共 Git 仓库中。
• 维护者称多个 GitHub 凭证被泄露，可能是通过 Claude Code 工具响应中泄露并被记录下来的 GitHub CLI OAuth 令牌，随后被收割。

企业镜像仓库与封存漏洞

• 维护者表示，企业客户使用的私有镜像仓库未受影响，并且已经收到了一个针对另一个未披露、仅限企业的、仍在封存期的漏洞的修复版发布。
• 有些人认为这是标准的协调披露；另一些人则认为，通过补丁差异向客户“提前出售对仍然保密漏洞的访问”在伦理上有问题。

对 LiteLLM 的信任与迁移讨论

• 许多人表示他们已经迁移离开，或者现在正在考虑这么做，认为对于一个非基础性依赖而言，两次供应链打击是不可接受的。
• 少数人则更宽容，强调许多生态都会发布封存期修复，而且复杂的发布流水线本来就很难保障安全。

缓解措施：冷却期、扫描与构建

• 很多人强烈支持对依赖项设置“冷却期”（24 小时到几天不等），以便在广泛采用前对新版本进行扫描，不过批评者认为这无法发现长期潜伏、隐蔽的恶意软件。
• 关于数据也存在争论：一些人声称重大供应链攻击通常会在几天内被发现；另一些人则坚持许多攻击会持续数月甚至数年（尚不明确/有争议）。
• 建议包括可复现构建、对 wheel 进行独立重建/比对、自动化恶意软件扫描（可能借助 LLM）、以及精选或商业镜像仓库。

沙箱、代理与凭证处理

• 有人主张将 LLM 网关（包括 LiteLLM 或替代方案）运行在严格的沙箱或代理中，其做法包括：
  • 在外部注入真实凭证，但向应用只暴露“虚拟”密钥。
  • 限制出站网络目的地。
  • 阻止文件系统访问常见的密钥位置。
• 也有人指出，这只是把供应链风险转移到了沙箱/代理工具本身。

替代方案与极简化

• 多位用户表示，他们用 Go 或 Rust 编写的小型自定义代理替换了 LiteLLM，或者改用更轻量的抽象层（例如基于 Pydantic 的客户端），认为在现代工具和 LLM 的帮助下，自建方案比依赖大型框架更便宜。
• 一些人推荐特定的极简、无依赖代理，并强调要积极削减依赖和锁定版本，而不是使用复杂路由器。

更广泛的生态与工具链担忧

• 包管理器因让自动安装和自动升级大型依赖树变得过于容易而受到批评，有人呼吁：
  • 内置冷却期，并默认禁用安装脚本。
  • 提供排除机制（例如使用 uv 等工具阻止特定包）。
• 人们对能够触及 shell、凭证和发布流水线的基于 LLM 的编码代理感到不安；多人主张大幅限制代理能力，并将关键步骤（提交、发布）手动处理。