2026-03-30 00:09:17 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 著名Python库LiteLLM遭供应链投毒，攻击者TeamPCP发布恶意版本窃取API密钥及云凭证。该库月安装量达9500万次，利用.pth机制触发攻击，波及DSPy等下游项目。文章建议受影响用户立即检查版本、轮换密钥并审计环境，强调建立默认不信任原则以应对开源供应链风险。 综合评分： 96 文章分类： 供应链安全,AI安全,应急响应,安全大事件,漏洞分析

cover_image

LiteLLM遭投毒：月安装量约9500万次，你的AI密钥可能已经被泄露

原创

黑客茶话会黑客茶话会

黑客茶话会

2026年3月26日 12:46 山东

LiteLLM遭投毒：月安装量约9500万次，你的AI密钥可能已经被泄露

【警告】恶意版本存活约3小时！你的API密钥可能已泄露！

2026年3月24日，AI开发者圈炸开了锅——著名AI科学家Andrej Karpathy（特斯拉前AI总监、OpenAI创始成员）紧急发帖，披露了一起震惊业界的供应链投毒事件：月均安装量高达9500万次的Python库LiteLLM被植入恶意代码，攻击者通过盗取PyPI维护者账户发布两个恶意版本（v1.82.7和v1.82.8），静默窃取API密钥、云凭证、SSH密钥等敏感数据。这不是一起普通的开源库安全事故——LiteLLM是连接OpenAI、Anthropic、Azure等主流AI服务的核心API网关，波及范围之广、影响之深，堪称2026年迄今最严重的AI供应链攻击事件。

一、事件始末：不到3小时，9500万次安装量的定时炸弹

1.1 Karpathy拉响警报，AI圈震动

事件的起因源于一次例行的”报警”。安全研究人员发现，LiteLLM v1.82.7和v1.82.8这两个版本在安装后系统行为异常——恶意代码利用Python的一个极高权限初始化机制（.pth文件机制），在pip install执行时就自动激活，无需显式import任何模块即可运行。这种攻击手法极其隐蔽，传统的静态分析工具几乎无法检测。

● 3月23日 — 攻击者盗取LiteLLM项目维护者的PyPI账户，准备投毒

● 3月24日凌晨 — 恶意版本v1.82.7和v1.82.8被发布到PyPI官方仓库

● 3月24日上午 — 恶意代码因内存泄漏导致系统异常，引发开发者注意

● 3月24日中午前 — PyPI紧急下架两个恶意版本，整个攻击窗口约3小时

● 3月25日 — Karpathy公开警告，安全社区大规模响应

● 3月26日 — 安全厂商发布完整技术分析和IOC指标

1.2 攻击者真实身份：TeamPCP组织浮出水面

安全研究人员通过分析攻击代码特征和攻击手法，确认此次LiteLLM投毒事件的幕后黑手是TeamPCP攻击组织。该组织此前已有多次供应链攻击前科：就在LiteLLM遭攻击前一天（3月23日），知名安全扫描工具Trivy的CI/CD管道同样被TeamPCP攻破。安全研究员Gal Nagli尖锐评价：”开源供应链已形成连锁崩塌——Trivy被攻破直接导致litellm沦陷，数万个生产环境的凭证已落入攻击者手中。”

二、技术剖析：.pth文件——披着羊皮的狼

2.1 恶意代码的启动机制

此次攻击的核心手法是利用Python的.pth文件机制。Python在启动时会自动执行site-packages目录下所有.pth文件中的代码，而攻击者在litellm_init.pth文件中写入恶意代码。这意味着：一旦执行pip install litellm，恶意代码就自动获得了最高执行权限，比任何应用代码都更早运行。

“这次投毒利用了Python语言设计层面一个极少被关注的安全盲区——.pth文件在import之前就已执行，属于pip install触发后的第一批动作。”

—— Checkmarx 安全报告

2.2 多阶段攻击载荷

恶意代码采用多阶段攻击设计，每一阶段都经过精心混淆：

第一阶段：环境侦察。代码自动扫描系统中的敏感路径，包括~/.ssh/、~/.aws/、~/.kube/、/etc/kubernetes/等目录，以及Shell历史记录文件（.bash_history、.zsh_history），识别所有可窃取凭据的位置。

第二阶段：数据压缩外传。收集到的敏感数据经ZIP压缩后，通过AES-256-CBC加密，再使用RSA-4096公钥加密传输密钥，最后通过HTTP POST请求外传到攻击者控制的服务器。

第三阶段：持久化控制。在Kubernetes环境中，恶意代码尝试通过提权Pod实现集群内横向移动，并植入systemd后门实现持久化控制——即便受害者重装系统，攻击者仍能重新入驻。

三、影响评估：谁在裸奔？

9500万

月均安装量

2个

恶意版本号

~3小时

存活窗口期

TeamPCP

攻击组织

3.1 直接影响范围

LiteLLM是AI开发者调用大模型API的事实标准接口，OpenAI、Anthropic Claude、Google Gemini、Azure OpenAI、HuggingFace等主流服务均通过它统一路由。安全公司eimoon的深度分析确认了两个恶意版本的外泄域名：

3.2 传递性影响：DSPy、CrewAI、MLflow用户也在射程内

更令人担忧的是”传递性中毒”效应。即便你的项目没有直接使用LiteLLM，但只要依赖链中某一环引用了受污染的LiteLLM版本，同样会受到波及。AI社区广泛使用的DSPy（编程框架）、CrewAI（多智能体框架）、MLflow（ML生命周期管理）等工具均可能间接受到影响。

四、应急响应：你现在该做什么？

【紧急】立即行动：检查你的LiteLLM版本

如果你在2026年3月23-24日期间执行过pip install litellm，必须立即进行安全审查。以下是具体排查步骤：

【实操】四步应急响应指南

第一步：检查版本。执行 pip show litellm，如果版本显示为1.82.7或1.82.8，立即断网隔离受影响机器
第二步：撤销并轮换所有密钥。立即在OpenAI、Anthropic、AWS/Azure/GCP等平台撤销可能暴露的API密钥和访问凭证
第三步：回滚版本。执行 pip install litellm==1.82.6，或彻底删除后重新安装安全版本
第四步：审计K8s环境。检查是否有异常Pod创建、systemd服务植入、以及异常网络出站流量

五、深度反思：开源AI供应链的至暗时刻

5.1 从Trivy到LiteLLM：连锁崩塌的警示

这起事件并非孤例。2026年3月短短几天内，Trivy（知名安全扫描工具）和LiteLLM相继被TeamPCP攻破，暴露了AI开源生态的深层脆弱性：CI/CD管道缺乏安全审计、PyPI账户缺乏强认证、依赖关系缺乏透明溯源。当一个环节被攻破，整个开源生态链就像多米诺骨牌一样接连倒塌。

5.2 开发者该如何自保？

面对日益复杂的供应链攻击，开发者需要建立新的安全思维：“默认不信任”原则——任何第三方依赖在引入生产环境前，都必须经过严格的安全审查；使用pip-audit、Dependabot等工具持续监控依赖漏洞；采用容器化隔离、最小权限等手段降低爆炸半径。

开源的本质是信任的传递。当你pip install一个包，你实际上是在信任这个包的作者、PyPI平台、以及整个依赖链上的每一个环节。这种信任，正在成为攻击者最理想的突破口。

LiteLLM投毒事件为整个AI行业敲响了警钟。在AI应用疯狂生长的时代，供应链安全不再是可选项，而是必选项。每一个开发者、每一个企业，都必须重新审视自己的代码依赖链——在AI时代，一个不起眼的pip install，可能就是一场灾难的起点。

【提示】特别提醒

本文目的不在制造恐慌，而在于推动安全意识的建立。建议所有AI从业者将此事件作为一次实战演练，审视自身项目的安全管理流程。安全不是负担，是AI时代的核心竞争力。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：黑客茶话会黑客茶话会黑客茶话会《LiteLLM遭投毒：月安装量约9500万次，你的AI密钥可能已经被泄露》