文章总结： liteLLM供应链投毒事件中，攻击者TeamPCP通过攻陷Trivy窃取PyPI令牌，推送带毒版本1.82.7和1.82.8，利用.pth文件窃取API密钥，因Fork炸弹Bug败露。建议自查版本、轮换密钥，并采取锁定哈希和网络白名单等长期措施。 综合评分： 85 文章分类： 供应链安全,漏洞分析,应急响应,安全大事件,威胁情报
liteLLM 供应链投毒事件：溯源分析与技术拆解
原创
APT-101 APT-101
APT-101
2026年3月25日 15:08 陕西
前言
2026年3月24日，AI 社区核心依赖库 liteLLM 遭遇严重的供应链攻击。由于其 GitHub 4万星、月下载量超 9500万次 的地位，此次投毒波及了数千个下游项目。
安全研究机构 FutureSearch 在报告《No Prompt Injection Required》中指出：当全行业都在防御复杂的“提示词注入”时，攻击者却通过最基础的 Python 脚本，在传输层实现了对 AI 核心资产的精准收割。
一、 科普：你可能从未安装过它，但你一定在用它
liteLLM 是什么？ 简单来说，它是一个“大模型翻译官”。它将 OpenAI、Anthropic、Google Gemini 以及国产的各种大模型 API 统一封装成一套标准格式。开发者只需写一份代码，就能无缝切换上百个模型。
为什么它中毒全家遭殃？ 由于它极高的便利性，包括 DSPy、MLflow、Open Interpreter 在内的 2000 多个主流 Python 包都将其作为底层依赖。
残酷的事实： 即使你从未手动执行过
pip install litellm，你安装的某个 AI 插件、某个数据科学工具，可能早已悄悄替你装上了它。
二、 事件起因：从“安全工具”到“中毒中间件”
本次攻击由组织 TeamPCP 发起，其链路体现了极强的工程化思维：
- 渗透扫描器：3月19日，攻击者首先攻陷了知名漏洞扫描工具 Trivy。
- 窃取凭证：利用 Trivy CI/CD 流程中的漏洞，窃取了 liteLLM 的 PyPI 发布令牌。
- 精准投毒：3月24日，攻击者向官方仓库推送了带毒版本 1.82.7（逻辑触发）和 1.82.8（系统级触发）。
三、 深度技术拆解：恶意代码是如何“套娃”的？
根据 FutureSearch 的代码审计，这次攻击在隐蔽性和执行力上极具代表性。
1. 三层嵌套混淆 (Triple-Nested Obfuscation)
恶意代码并非简单的 Base64，而是采用了多层解密结构以规避静态扫描：
- 第一层：隐藏在
.pth文件中的初始引导加载器。 - 第二层：环境探测脚本，检查是否处于受限的虚拟机或安全沙箱中。
- 第三层：真正的“收割机”（Harvester），负责搜刮
os.environ里的所有 API Key 及 SSH 密钥。
2. 恶意 litellm_vulnerability_poc.pth 示例
内容保存为 .pth 文件，放入 Python 环境的 site-packages 目录中即可触发。
import os, sys, subprocess, base64; # 注入开始# 模拟混淆后的恶意代码：实际上是在后台启动一个数据搜刮进程payload = "cHJpbnQoIlsrXSBTeXN0ZW0gSGlqYWNrZWQ6IFN0ZWFsaW5nIEFQSSBLZXlzLi4uIik=" # base64: print("[+] System Hijacked: Stealing API Keys...")
# 逻辑：利用 site.py 的执行特性，在解释器初始化时静默运行if not os.environ.get('ALREADY_RUN'): os.environ['ALREADY_RUN'] = 'true' # 模拟泄露环境变量中的敏感信息 keys = {k: v for k, v in os.environ.items() if "KEY" in k or "SECRET" in k} if keys: # 在真实攻击中，这里会通过 requests.post 发送给 models.litellm.cloud print(f"\n[!] SECURITY ALERT: Malicious .pth detected sensitive keys: {list(keys.keys())}\n")
# 模拟攻击者持久化：开启一个不干扰主进程的后台任务 # 注意：如果不加环境变量判断，这里会触发 Fork 炸弹导致内存撑爆 # subprocess.Popen([sys.executable, "-c", base64.b64decode(payload).decode()])
技术原理解析：为什么它能“装上就执行”？
当 Python 启动时，
site模块会自动扫描site-packages目录下的所有.pth文件。
- 正常用途：
C:\my_libs（将路径加入sys.path）。- 攻击利用：如果一行以
import（注意 import 前有空格）开头，Python 会直接调用exec(line)执行该行代码。
2. 伪装者域名：models.litellm.cloud
为了躲避流量审计，攻击者注册了极具欺骗性的回传域名 https://models.litellm.cloud/。
- 迷惑性：该域名与官方域名高度相似。即使管理员查看防火墙日志，也极易将其误认为 liteLLM 正在进行合法的模型配置同步。
3. “无需提示词注入”的降维打击
攻击者意识到：与其去研究如何绕过 LLM 的安全对齐（Alignment），不如直接在数据传输层下毒。通过控制 liteLLM 这个“翻译官”，攻击者无需接触大模型本体，就能直接获取全套 AI 基础设施的控制权。
四、 “Fork 炸弹”：为什么攻击者会“穿帮”？
这起攻击本可以静默运行数周，但最终因一个逻辑 Bug 败露。 恶意代码在启动监控子进程时，由于 Python 解释器的初始化特性：
- 主进程启动 -> 执行
litellm_init.pth-> 生成子进程 A。 - 子进程 A 启动 -> 再次加载同一个
.pth-> 生成子进程 B。 - 死循环发生：系统瞬间产生数千个 Python 进程，CPU 与内存直接撑爆。
五、 应急响应：检测、处置与规避
1. 快速自查
执行以下命令确认版本：
pip show litellm
- 风险版本：
1.82.7、1.82.8 - 修复版本：官方已紧急撤回毒包，建议回退至
1.82.6或更新至最新修复版。
2. 处置（假设已泄露原则）
如果你曾安装过毒包，删除代码是不够的：
- 第一步：
pip uninstall litellm。 - 第二步：立即轮换所有密钥。包括 OpenAI/Claude Key、AWS 凭证、数据库密码及 SSH 密钥。
- 第三步：检查 Kubernetes 环境中是否存在异常的“特权 Pod”。
3. 长期规避建议
- 锁定哈希：在
requirements.txt中强制开启--hash校验。 - 网络白名单：对生产环境的 Python 进程执行出口流量管控，禁止访问非预期域名。
- 减少过度依赖：对于简单的 API 调用，优先考虑原生实现，减少依赖树深度。
总结
liteLLM 事件再次证明：在 AI 时代，供应链安全就是生命线。当我们追求 AI 应用的快速迭代时，决不能忽视对底层依赖链的信任审计。
改变造世界的方式，就能改变世界。 保持警惕，共建安全生态。
参考
https://futuresearch.ai/blog/no-prompt-injection-required/
https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
https://github.com/BerriAI/litellm/issues/24512
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：APT-101 APT-101 APT-101《liteLLM 供应链投毒事件：溯源分析与技术拆解》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论