如果你在生产环境中运行LiteLLM，你可能经历了一个艰难的星期。

在2026年3月24日，两个被植入后门的litellm版本（1.82.7和1.82.8）使用被盗的凭证发布到了PyPI。该恶意软件窃取了SSH密钥、AWS/GCP/Azure凭证、Kubernetes秘密、加密货币钱包，并在受感染的机器上部署了持久性后门。它的在线时间大约为3小时。LiteLLM每天的下载量达到340万次。

以下是事件的完整解析，包括发生了什么、为什么这很重要以及你应该如何应对。

发生了什么：完整的攻击链

这次攻击并不是从LiteLLM开始的，而是从Trivy，一个流行的容器安全扫描工具开始的。

以下是事件的顺序：

1. 一个名为 TeamPCP 的威胁行为者组织利用了 Trivy 的 GitHub Action 中的 pull_request_target 工作流漏洞 (GHSA-9p44-j4g5-cfx5)
2. 他们利用这一漏洞窃取了 aqua-bot 的凭证，并将 Trivy v0.69.4 的发布标签重写为指向恶意负载
3. 在 3 月 23 日，他们还使用类似技术攻陷了 Checkmarx KICS GitHub Action
4. LiteLLM 的 CI/CD 流水线在没有固定到特定版本或提交 SHA的情况下拉取了 Trivy Action
5. 恶意的 Trivy Action 从 GitHub Actions 运行器中窃取了 LiteLLM 的 PYPI_PUBLISH 令牌
6. 利用被盗的令牌，TeamPCP 以合法凭证向 PyPI 发布了两个后门版本

完整的时间线记录在 Snyk 的分析 和 Wiz 的归因分析 中。

恶意软件：三阶段损害

这不是一个简单的凭证窃取者。它是一个设计用于最大程度提取和持久性的三阶段有效载荷。

第一阶段：信息收集

恶意软件收集了：

• 系统数据（主机名、环境变量、进程、网络路由、身份验证日志）
• SSH 私钥、.env 文件、Git 凭证
• 来自 shell 历史的 API 密钥
• Slack 和 Discord 的 webhook 令牌
• Jenkins、Travis CI 和 Terraform 配置
• /etc/shadow 密码哈希
• 完整的 AWS 凭证链，包括 IMDSv2、Secrets Manager 和 SSM 参数存储
• GCP 和 Azure 服务账户文件
• Docker config.json 和 Kubernetes kubeconfig、服务账户令牌、秘密和证书
• 加密货币钱包文件（比特币、以太坊、索拉纳、卡尔达诺、门罗币、Ledger 硬件钱包配置）

第二阶段：加密与外泄

所有内容被打包，使用 AES-256-CBC 加密，会话密钥用硬编码的 4096 位 RSA 公钥进行包装，并外泄到 models.litellm.cloud，该域名在攻击前仅注册了一天。

阶段 3：持久性和横向移动

该恶意软件在 ~/.config/sysmon/sysmon.py 安装了一个持久性后门，并通过一个 systemd 服务每 5 分钟轮询 checkmarx.zone 以获取新的有效载荷。在 Kubernetes 环境中，它读取了所有命名空间中的所有秘密，并在每个 kube-system 节点上部署了 特权 Pod，挂载了主机文件系统。

来源：Snyk 的完整技术分析

两种投递机制（这部分很可怕）

版本 1.82.7 将一个 Base64 编码的有效载荷直接嵌入到 litellm/proxy/proxy_server.py 中。每当导入 litellm.proxy 时，它就会执行。

版本 1.82.8 增加了一些更糟糕的东西：一个名为 litellm_init.pth 的文件被放置在 site-packages/ 中。Python 的 .pth 机制在每次解释器启动时都会触发。这意味着恶意软件在你运行 pip install 时、在你的 IDE 启动语言服务器时、在你运行 python -c "print('hello')" 时都会运行。这与导入 litellm 无关。

这属于 MITRE ATT&CK T1546.018（Python 启动钩子）。该 .pth 文件在 wheel 的 RECORD 文件中被正确声明，因此 pip install --require-hashes 会通过。

受影响的项目

受影响的版本被引入到多个主要项目中：

Aider 能够幸存下来是因为它固定了其依赖版本。这个决定改变了一切。

标准防御如何失败

此次攻击绕过了几乎所有标准保护：

• 哈希验证通过，因为这些包是使用合法的被盗凭证发布的
• 没有发现拼写欺诈。包名正是 litellm
• 安装时没有可疑域名。外泄域名是 models.litellm.cloud，看起来是合法的
• pip install --require-hashes 会通过，因为 .pth 文件在 wheel 的 RECORD 中被正确声明

唯一能够在安装时捕获此问题的防御措施是检查包是否安装了包含 subprocess、base64 或 exec 模式的 .pth 文件。目前没有广泛部署的 pip 插件能够自动执行此操作。

机器人抑制活动

当研究员 Callum McMahon at FutureSearch 在 GitHub 问题 #24512 中报告了这一漏洞时，TeamPCP 使用 73 个先前被攻陷的 GitHub 账户 在 102 秒内发布了 88 条垃圾评论，然后使用被攻陷的维护者账户 krrishdholakia 将该问题关闭，理由是“未计划”。

76% 的这些账户与在 Trivy 披露期间使用的僵尸网络重叠。这在 Wiz 的分析 中有详细记录。

没有人谈论的结构性问题

LiteLLM 是一个 Python 包。它位于您的应用程序与 LLM 提供者之间。它持有 OpenAI、Anthropic、AWS Bedrock、Google Vertex 以及您通过它路由的其他服务的 API 密钥。它从设计上就是一个高价值的目标。

而且它运行在一个这样的语言中：

• 任何包都可以安装在解释器启动时执行的 .pth 文件
• 传递依赖会引入您从未明确选择的数十个包
• 一个被攻破的 CI/CD 令牌可以在受信任的包名称下发布任意代码
• 全局解释器锁（GIL）意味着您需要运行多个进程，每个进程独立触发 .pth 执行

这并不是对 Python 作为一种语言的批评。Python 在其擅长的领域表现出色。但问题在于，Python 是否是承载您最敏感凭证并处于每个 LLM 请求的关键路径上的基础设施的正确选择。

像 Go 和 Rust 这样的编译语言生成的单个二进制文件没有运行时依赖链。没有 site-packages 目录。没有 .pth 执行机制。没有 pip install 的副作用。攻击面从根本上来说更小。

你现在应该做的事情

1. 检查你的 LiteLLM 版本

pip show litellm | grep Version

如果您看到版本 1.82.7 或 1.82.8，您可能受到影响。LiteLLM 的安全更新 确认这些版本已被攻破。

2. 扫描 .pth 文件

find $(python -c "import site; print(site.getsitepackages()[0])") -name "*.pth" -exec grep -l "subprocess\|base64\|exec" {} \;

3. 旋转所有内容

如果你运行了被攻击的版本，请假设该机器上的所有凭证都已被泄露：

• • AWS/GCP/Azure 密钥和服务账户

• • SSH 密钥

• • API 密钥（OpenAI、Anthropic 等）

• • 数据库密码

• • Kubernetes 服务账户令牌

• • CI/CD 令牌

4. 固定你的依赖项

Aider 能够幸存下来是因为它固定了 litellm==1.82.3。请固定你的版本。更好的是，通过哈希值进行固定：

litellm==1.82.6 --hash=sha256:<known-good-hash>

5. 通过 SHA 锁定您的 CI/CD 操作

不要这样做：

uses: aquasecurity/trivy-action@latest

这样做：

uses: aquasecurity/trivy-action@