LiteLLM 受到不断增长的打击TeamPCP 供应链活动2026 年 3 月 24 日，攻击者发布了两个恶意 PyPI 版本：1.82.7 和 1.82.8。维护 LiteLLM 的 Berri AI 确认了这一泄露，并表示它可以追溯到其 CI/CD 路径中受损的 Trivy 安全扫描依赖项。
该事件很重要，因为恶意软件包不仅仅破坏了构建。安全研究人员表示它们包含一个凭证收集器、以 Kubernetes 为中心的横向移动逻辑，以及旨在在初始安装后继续存在的持久机制。 Endor Labs 表示，有效负载针对 SSH 密钥、云凭证、Kubernetes 机密、加密货币钱包和.env文件。
任何安装并运行这些受损版本的人都应该假设秘密已经暴露。 Berri AI 告诉用户在安装了 LiteLLM 1.82.7 或 1.82.8 的任何系统上轮换作为环境变量或配置文件出现的所有凭据。
Endor Labs 描述了此次攻击作为三级有效负载。据称，该恶意软件首先获取凭据，然后通过部署特权 Pod 尝试 Kubernetes 横向移动，最后安装一个持久后门，轮询攻击者基础设施以获取后续有效负载。
Wiz 报告称，两个恶意 LiteLLM 版本使用了不同的执行方法。根据 Wiz 的说法，1.82.7 版本运行有效负载时litellm.proxy.proxy_server被进口或何时进口litellm --proxy被使用，而1.82.8版本添加了一个更危险的.pth基于 的启动器，每当 Python 启动时自动执行。
那.pth细节很重要，因为它扩大了爆炸半径。 Berri AI 的 GitHub 问题说litellm_init.pth在Python解释器启动时自动运行，这意味着攻击者不需要受害者在安装后直接导入LiteLLM。
LiteLLM 妥协一览
| 物品 | 确认详情 |
|---|---|
| 受影响的套餐 | LiteLLM 是 PyPI |
| 恶意版本 | 1.82.7 和 1.82.8 |
| 首次公开检测 | 2026 年 3 月 24 日 |
| 经维护者确认 | 是的，Berri AI 确认妥协 |
| 可能的初始来源 | CI/CD 中 Trivy 扫描依赖性受损 |
| 最危险的机制 | .pth1.82.8版本自动执行 |
为什么1.82.8版本更糟糕
1.82.8 版本似乎是这两个版本中更危险的一个。 Berri AI 问题报告和 Wiz 的分析均表示该轮盘包含恶意软件litellm_init.pth文件放置在wheel根目录下，导致代码在Python启动时自动运行。
维兹说.pth启动器在后台生成一个子 Python 进程，这使得行为更加隐蔽，并且与正常的 LiteLLM 执行的联系更少。这意味着安装了 Python 的环境（包括开发人员工作站、CI 运行程序和生产容器）可能会在比用户预期更广泛的情况下触发有效负载。
相比之下，1.82.7 似乎依赖于注入的代码litellm/proxy/proxy_server.py，这仍然使它很危险，但与模块导入或特定于代理的执行路径更加相关。
这如何与更广泛的 TeamPCP 活动联系起来
LiteLLM 事件并不是孤立发生的。Endor Labs 和 Wiz 均采用框架它是与 TeamPCP 早期涉及 Trivy 和其他供应链组件的妥协相关的后续攻击。从这个意义上说，LiteLLM 看起来像是选择的关键目标，因为上游 CI/CD 暴露为下一阶段提供了新的凭证。
这种模式与 Endor Labs 的公开声明相符，该声明警告称，该活动可能仍在扩大。其研究人员表示，TeamPCP 表现出了一种一致的模式，即一个受感染的环境会产生解锁下一个目标的凭据。
维兹以更强烈的措辞表达了同样更广泛的观点，称这一妥协反映了整个生态系统的级联，一个漏洞会引发下一个漏洞。这一框架符合防御者在 Trivy、KICS 和其他与 TeamPCP 相关的事件中已经看到的情况。
团队应立即检查哪些内容
- 任何环境是否安装了LiteLLM 1.82.7或1.82.8
- 无论
litellm_init.pth存在于site-packages - 出站流量至
models.litellm.cloud或者checkmarx.zone - Kubernetes 集群中异常的特权 Pod
- 意外的 systemd 持久性，例如
sysmon.service
Berri AI 和捍卫者说现在应该做什么
Berri AI 表示，受感染的软件包 1.82.7 和 1.82.8 已被删除，维护者帐户已轮换，并且在发布链经过审查之前不会发布新的 LiteLLM 版本。它还表示 LiteLLM 代理 Docker 镜像用户没有受到影响，因为依赖项被固定在requirements.txt.
对于暴露用户的反应更为紧急。 Berri AI 表示，任何安装了这些版本的人都应该轮换受影响系统上作为环境变量或配置文件存在的所有凭据。 PyPI 相关的咨询和第三方供应商报告呼应了相同的指导。
安全团队还应该隔离受影响的主机，检查 Kubernetes 集群中是否存在恶意 pod，删除持久性，并审核在受损窗口期间使用 Trivy 或 KICS 的 CI/CD 工作流程。这些步骤在供应商指南中一致出现，并且符合 Endor Labs 和 Wiz 报告的恶意软件行为。
FAQ
哪些 LiteLLM 版本是恶意的？
已确认的恶意 PyPI 版本为 1.82.7 和 1.82.8。 Berri AI 表示，在发现漏洞后，两者均已被删除。
这和Trivy事件有关吗？
是的。 Berri AI 表示，此次泄露源于 Trivy 安全扫描依赖性，多个安全供应商将该事件与更广泛的 TeamPCP 活动联系起来。
为什么 LiteLLM 1.82.8 特别危险？
因为其中包含了恶意.pth文件在 Python 启动时自动执行，而不仅仅是在导入 LiteLLM 代码时。
受影响的用户首先应该做什么？
隔离受影响的系统，删除恶意软件包，检查持久性，并轮换环境可以访问的每个凭据。 Berri AI 特别表示要轮换作为环境变量或配置文件存在的所有凭据。