LiteLLM投毒事件最终报告披露：40分钟攻击窗口，2500家企业、195TB凭据数据外泄，英伟达等巨头在列。这不是演习，是AI供应链安全的警钟。

凌晨三点，你的手机震了。不是闹钟，是监控告警——CI/CD流水线里的API密钥正在被外传。你翻了个身想继续睡，下一秒清醒了：那不是误报。

这不是假设场景。今年3月，全球约2500家企业经历了这样一个凌晨。安全公司CloudSEK和Hudson Rock本周披露的完整分析报告显示，LiteLLM投毒事件在约40分钟的攻击窗口内，卷走了195TB的凭据数据。CloudSEK直接将此次事件定义为2026年最大规模的AI供应链泄露。

195TB是什么概念？按一份标准环境变量文件约2KB算，这相当于近千份配置文件的体量。实际泄露数据当然有大量冗余，但这个数字扔出来，做安全的人还是会背后发凉。

一、40分钟，从投毒到洗劫

LiteLLM是什么？如果你公司的AI团队在用Python调OpenAI、Anthropic或者Azure的API，大概率绕不开它。这个开源AI API网关月均下载量接近1亿次，每天被安装约340万次，是AI基础设施里的”水电煤”。

攻击者TeamPCP的手法并不高明，但足够有效。他们没有直接攻击LiteLLM本身，而是盯上了LiteLLM的CI/CD流水线里用到的一个安全扫描工具——Trivy。攻击者重写了Trivy的Git标签，把恶意代码塞进了v0.69.4版本。LiteLLM的流水线没有锁定Trivy的具体版本号，每次都拉最新版。恶意代码就这样混进了构建环境，偷走了PyPI的发布令牌。

拿到令牌后，攻击者向PyPI推送了两个带毒的LiteLLM版本：1.82.7和1.82.8。从上传到PyPI隔离，整个过程不到3小时。但这3小时里，恶意版本被下载了超过11.9万次。

恶意代码干了什么？简单说，它把受害者机器上能找到的所有凭据都打包传了出去——云服务商密钥、Git仓库Token、SSH私钥、Kubernetes配置、环境变量、AI服务商的API Key。CloudSEK在那份195TB的泄露文件里，光CI/CD流水线凭据就找到了约43.4万条。

二、你的密钥，可能已经在暗网上了

最让人不安的不是泄露规模，而是影响的广度。研究人员在分析泄露数据后明确表示，有充足证据显示包括英伟达在内的多家科技巨头受到了影响。

CloudSEK的报告显示，暴露的凭据类型几乎覆盖了现代软件开发的所有环节：AWS、Azure、GCP的访问密钥；GitHub、GitLab的私有仓库Token；SSH登录密钥；Kubernetes集群的管理配置；npm、PyPI的软件包发布凭据；以及OpenAI、Anthropic等AI服务商的API Key。

更要命的是，这些凭据不是孤立的。拿到你的AWS密钥，攻击者就能进你的云环境；拿到你的Git Token，就能往你的代码库里塞后门；拿到你的K8s配置，就能控制你的整个容器集群。这是一串完整的攻击链条，每一环都可能成为下一次入侵的起点。

PyPI官方的事后报告里有个细节值得注意：从恶意包上传到第一个用户举报，间隔了1小时19分钟。也就是说，在这个时间窗口内，没有任何自动化安全机制发现异常。一个日均安装340万次的包，被投毒后居然要靠人肉举报来发现。

还有个更离谱的事。如果不是恶意代码本身有个实现缺陷——.pth启动器会触发递归分叉炸弹，把受害者的机器直接搞崩溃——这个恶意软件本可以静默运行更长时间。Karpathy在X上说了一句大实话：如果不是因为这个bug，造成的破坏会大得多。

三、供应链安全，不是”下次注意”就能解决的

每次出了供应链安全事件，行业里的标准反应就是”加强审计””锁定版本””注意来源”。这些建议都对，但说了等于没说。

真正的问题在于：现代软件开发对开源依赖的信任模型已经崩了。一个典型的Python项目，直接依赖可能有几十个，传递依赖轻松上千。你pip install一个包，实际上是在信任这个包的所有上游维护者。LiteLLM事件里，攻击者甚至没有直接攻击LiteLLM的代码仓库，而是攻击了它CI/CD流水线里的一个第三方工具。

这意味着什么？你的攻击面不只是你写的代码，而是你的整条构建链。GitHub Actions里引的每一个Action、Docker镜像里的每一个layer、npm install拉下来的每一个包，都可能是下一个入口。

那怎么办？几句实在话：

第一，锁死依赖版本。requirements.txt里别写>=，用==精确锁定。生产环境加–require-hashes，确保每次安装的包哈希一致。

第二，审计CI/CD流水线。检查你的GitHub Actions里引用的每一个第三方Action，确认它们锁定了具体的commit hash而不是latest标签。LiteLLM就是因为没锁Trivy版本才中招的。

第三，凭据轮换别拖。如果你的企业在今年3月24日前后安装过LiteLLM 1.82.7或1.82.8，所有相关的API密钥、云凭据、SSH密钥都应该立即轮换。别抱侥幸心理，攻击者不会等你。

第四，监控环境变量。在CI/CD流水线里部署环境变量泄露检测，任何试图把环境变量内容外传到非白名单域名的行为都应该触发告警。

四、AI时代，供应链攻击只会越来越多

这次事件有个容易被忽略的背景：LiteLLM不是普通的Python包，它是AI基础设施的核心组件。攻击者选择它，看中的就是AI行业对这类工具的深度依赖。

随着AI应用的大爆发，围绕AI工具链的供应链攻击只会越来越频繁。模型权重文件、训练数据集、推理框架、向量数据库——每一个环节都可能成为攻击目标。你花几百万训练的模型，可能因为一个依赖包被投毒就全部泄露。

安全团队需要把AI工具链纳入供应链安全管理范畴，像审计生产代码一样审计AI依赖。这不是可选项，是必选项。

---

40分钟，195TB数据，2500家企业。这组数字背后，是整个行业对开源供应链信任体系的一次集体警醒。下一个LiteLLM会是谁？没人知道。但攻击者已经盯上了AI基础设施这条赛道，你的防御体系不能还停留在上一个时代。

（信息来源：Ars Technica、CloudSEK、Hudson Rock、PyPI官方事件报告、InfoQ）