与 Trivy 黑客事件相关的恶意 LiteLLM 版本可能已暴露超过 2,100 家组织

导语：本报道聚焦三月份在 PyPI 上短暂出现的两个恶意 LiteLLM 版本（1.82.7 和 1.82.8），其内置的凭证窃取载荷与更广泛的 TeamPCP 供应链攻击及 Trivy 扫描器入侵事件存在关联。CloudSEK 通过对约 43.4 万份被截获文件的分析，绘制出超过 2,500 家组织的潜在暴露图谱。

两个恶意的 LiteLLM 版本三月份曾在 PyPI 上存在约 40 分钟，其中包含凭证窃取代码，能够从安装了该软件包的系统中收割云密钥、SSH 密钥、Kubernetes 令牌、数据库密码以及其他机密。

威胁情报公司 CloudSEK 表示，其获取的一份数据集由攻击者截获的大约 43.4 万个文件构成，将潜在暴露范围映射到超过 2,500 家组织。

需要指出的是，这些总数并非受害者数量。CloudSEK 告诉 The Hacker News，相关的素材来自机密情报来源，由其评估为属于此次行动的截获赃物和日志文件组成，并非从其所列出的组织处收集而来。换言之，这些文件是被窃取的。

高置信度匹配所断言的是每个文件来自哪一方的系统。该判断依据的是截获的 CI runner 环境中的身份信号，主要是主机身份和合法的 committer 域名，组织的自有域名必须出现，匹配才能获得最高评级。仅凭代码仓库命名空间只能给出中等置信度判定。NVIDIA、Cisco、Deloitte、Volkswagen、FedEx、Siemens 以及 X Corp 都出现在名单中，但这并不证明被盗凭证已被使用，因此 CloudSEK 和 LiteLLM 都建议受影响方主动轮换凭证，而非等待证据确认。

LiteLLM 是一个开源的 AI 网关，用于将应用程序连接到多个模型提供商。该项目确认 1.82.7 和 1.82.8 版本遭到破坏，并表示这两个版本于 3 月 24 日 UTC 时间 10:39 上线，在 PyPI 将其隔离前存在约 40 分钟，但官方建议将当日 UTC 时间 16:00 之前的任何安装都视为可疑。The Hacker News 于 8 月 12 日通过 PyPI 确认，这两个版本在该软件包的发布历史中均未出现，而 1.82.6 和 1.83.0 仍可获取。

FBI 在 7 月 2 日发布的 FLASH-20260702-01 警告中指出，附属行为者很可能在初次入侵之后很长时间内武器化在 TeamPCP 行动中外泄的凭证。FBI 建议组织在相关暴露窗口期间轮换 CI/CD 凭证、发布令牌以及云凭证。

在该窗口期间被复制出的长期有效凭证——例如静态云密钥、SSH 密钥或发布令牌——除非此后被轮换或撤销，否则仍然可用。这就是 FBI 的指南针对的是凭证而非软件包本身的原因，也是该局和 Aqua 都建议团队从长期令牌转向临时令牌的原因。

1.82.8 版本包含一个名为 litellm_init.pth 的文件，Python 进程在解释器启动时会加载该文件，因此只要该环境中启动任何 Python 进程就会执行，无论是否有任何代码导入 LiteLLM。

被植入恶意代码的软件包被设计为收集环境变量、SSH 密钥、云凭证、Kubernetes 令牌以及数据库密码，然后对窃取的数据进行加密并发送至 models.litellm[.]cloud 这一与项目无关的攻击者控制域名。Unit 42 的行动分析记录到，载荷会读取保存模型 API 密钥的环境变量，包括 OPENAI_API_KEY 和 ANTHROPIC_API_KEY。

这种行为颠覆了通常的应急响应问题。某个团队是否主动使用 LiteLLM 并不重要，关键是有没有任何主机上的程序安装过它；项目的公告指出，未固定版本的传递性依赖（包括被智能体框架或编排工具引入的版本）可能在团队并未主动选择的情况下将其带入系统。

LiteLLM 事件属于更广泛的 TeamPCP 供应链行动的一部分，该行动与 Aqua Security 的 Trivy 扫描器相关联。Google 将 TeamPCP 追踪为 UNC6780。Aqua 表示，攻击者在凭证轮换不完整后保留了访问权限，并于 3 月 19 日向全部 76 个 trivy-action 版本标签以及全部 7 个 setup-trivy 标签强制推送了恶意提交，同时发布了一个恶意的 Trivy 0.69.4 版本。

该生态系统的攻陷事件被追踪为 CVE-2026-33634，并于 3 月 26 日被加入 CISA 的已知被利用漏洞目录。The Hacker News 于 8 月 12 日确认，该 CVE 记录目前已将 BerriAI LiteLLM 1.82.7 至 1.82.8 与相关 Trivy 组件一同列为受影响对象。

恶意 LiteLLM 版本究竟是如何到达 PyPI 的，在不同的公开报告中存在分歧。CloudSEK 的报告称，被污染的构建过程生成并发布了这些版本；LiteLLM 自身的 incident report 则指向一次绕过其官方 CI/CD 工作流的直接 PyPI 上传；Unit 42 则描述攻击者在 Trivy 漏洞事件后针对 PyPI 发布令牌进行攻击。被问及这一分歧时，CloudSEK 进行了反驳。该公司告诉 The Hacker News："这些是同一攻击链的不同阶段，并非相互对立的解释。"其证据覆盖了凭证是如何被获取的，而 LiteLLM 和 Unit 42 的发现覆盖了凭证随后是如何被使用的。

PyPA 针对恶意版本的公告描述了同样的顺序：通过遭入侵的 Trivy 依赖暴露了一个 API 令牌，随后该令牌被用于上传这两个版本。截至本文撰稿时，BerriAI 尚未就其自身取证结果支持哪一账户的说法回应问询。

来源信息

来源：The Hacker News

原文链接：https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html

作者：info@thehackernews.com (The Hacker News)