文章总结： LiteLLM1.82.7和1.82.8版本被发现存在后门，攻击者通过PyPI供应链投毒，植入窃取凭证、Kubernetes横向移动及持久化后门的恶意代码。特别是1.82.8版本利用.pth文件实现零点击触发。文章详细分析了攻击链、IOC指标及排查清理步骤，建议用户立即卸载受影响版本并降级至1.82.6，同时轮换相关凭证，加强供应链安全防护。 综合评分： 89 文章分类： 供应链安全,恶意软件,应急响应,威胁情报,漏洞分析

litellm 1.82.7 和 1.82.8 后门自查指南

Ots安全

2026年3月25日 13:49 广东

威胁简报

恶意软件

漏洞攻击

攻击详情

受影响版本：

• 1.82.7：恶意代码注入在 litellm/proxy/proxy_server.py 文件中，需要 import litellm 才会触发。

• 1.82.8（更危险）：额外添加了一个 litellm_init.pth 文件，只要 Python 进程启动（即使不 import litellm），恶意代码就会自动执行。

• 恶意行为（三阶段攻击）：凭证窃取：扫描并窃取 SSH keys、AWS/GCP/Azure 等云凭证、Kubernetes secrets、.env 文件、数据库密码、加密货币钱包、LLM API keys 等。

• 横向移动：如果检测到 Kubernetes 服务账号令牌，会在集群每个节点上创建 privileged pod，挂载主机文件系统，进一步扩散。

• 持久化后门：安装 systemd 服务（sysmon.service / sysmon.py），定期从 C2 服务器（类似 checkmarx.zone/raw 或 models.litellm.cloud）拉取额外 payload。

这些恶意版本绕过 GitHub 正常 release 流程，直接上传到 PyPI，已被 PyPI 官方移除。LiteLLM 官方确认攻击很可能源于他们 CI/CD 中使用的 Trivy 被先前妥协，导致 PyPI 发布凭证泄露。

LiteLLM 是非常流行的 LLM 代理库（每月上亿下载），很多 AI 项目、代理、DSPy 等都会依赖它，所以影响面不小，但好在恶意版本上线时间很短（约 1-2 小时）。

1.检查版本：

pip show litellm

或者在所有虚拟环境、CI/CD、Docker、Kubernetes pod 中检查。

2.如果装了 1.82.7 或 1.82.8：

立即卸载并降级到 安全版本（推荐 1.82.6 或更早的干净版本）：

pip uninstall litellmpip install litellm==1.82.6

清空缓存（防止从本地缓存重新安装）：

pip cache purgerm -rf ~/.cache/pip ~/.cache/uv   # 如果用 uv

3.检查持久化痕迹：

• 本地：查看 ~/.config/sysmon/sysmon.py 或类似路径
• Kubernetes：检查是否有异常 privileged pod（alpine:latest 等）

LiteLLM 1.82.7 / 1.82.8 后门 的详细技术分析（基于 Endor Labs、Armo、JFrog、SafeDep、FutureSearch 等安全研究机构的逆向分析）。

1. 注入方式对比（两个版本的区别）

• 1.82.7（较“温和”）：

• 恶意代码仅注入在 litellm/proxy/proxy_server.py 文件中（大约在第 128 行左右）。

• 注入位置：位于两个合法代码块之间（REALTIME_REQUEST_SCOPE_TEMPLATE 字典和 showwarning 函数之间），插入了约 12 行代码。

• 触发条件：必须 import litellm.proxy.proxy_server（或间接 import 相关模块）才会执行。

• GitHub 源码对应 commit 中没有这些代码，说明是在 wheel 打包过程（或之后）被注入的。

• 1.82.8（更危险，“零点击”）：

• 同时包含 1.82.7 的 proxy_server.py 注入。

• 额外添加一个文件：litellm_init.pth（大小约 34,628 字节，位于 wheel 根目录）。

• 触发条件：只要 Python 解释器启动（任何 Python 进程），Python 的 site 模块就会自动执行 .pth 文件中的代码，无需任何 import。

• 这意味着：打开 Python REPL、运行 pytest、执行 Django 命令、CI/CD pipeline 等都会触发恶意代码。

.pth 文件内容本质上是单行（高度压缩）：

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('...长base64字符串...'))"], stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, start_new_session=True)

它通过 subprocess.Popen 启动一个后台子进程来执行真正的 payload（避免阻塞主进程）。

遗憾的是，这个设计有一个 bug：子进程启动后又会再次触发 .pth，导致指数级 fork bomb（进程爆炸），最终耗尽内存/CPU。这也是最初被发现的原因（某开发者机器直接崩溃）。

2. Payload 结构（三阶段攻击）

恶意代码采用多层 base64 混淆（三重嵌套）：

• 最外层（proxy_server.py 或 .pth 中）：base64 字符串 → 解码后是一个小型 orchestrator（启动器）。
• 第二层：解码出一个更大的 base64 blob。
• 第三层：真正的 credential harvester + lateral movement + persistence 逻辑。

Stage 1: 凭证窃取（Credential Harvester）

扫描常见敏感路径和文件：

• ~/.ssh/（私钥、config）
• ~/.aws/, ~/.gcp/, ~/.azure/, ~/.kube/, ~/.docker/
• 所有 .env 文件、.git-credentials、shell history（.bash_history 等）
• 数据库密码、LLM API keys（OpenAI、Anthropic 等）、crypto wallets
• Kubernetes secrets、云元数据服务（IMDS）
• 进程内存中匹配的 secret 模式

1. 收集后打包成 tpcp.tar.gz（文件名固定）。
2. 加密方式：AES-256-CBC（随机 session key） + 4096-bit RSA 公钥（硬编码在 payload 中）加密 session key。
3. 外发：POST 到攻击者控制的服务器，Header 包含 X-Filename: tpcp.tar.gz。

Stage 2: Kubernetes 横向移动（仅当检测到 K8s service account token 时）

• 读取整个集群所有 namespace 的 secrets。
• 在每个节点上创建 privileged pod（镜像通常是 alpine:latest，名称如 node-setup-*，命名空间 kube-system）。
• Pod 会挂载宿主机文件系统（hostPath），从而：在宿主机上安装持久化后门，

进一步扩散到整个集群。

Stage 3: 持久化后门

在宿主机上安装：

• ~/.config/sysmon/sysmon.py（核心后门脚本）
• ~/.config/systemd/user/sysmon.service（伪装成 “System Telemetry Service” 的用户级 systemd 服务）

1. 服务特性：

2. 每隔约 50 分钟（或固定间隔）轮询 C2。

3. C2 域名：https://checkmarx.zone/raw（或 models.litellm.cloud 用于 exfil）

4. 下载并执行任意后续 payload。

5. 自重启机制（Killed 后 10 秒内重启），stdout/stderr 重定向到 /dev/null。

6. 注册方式：systemctl –user enable –now sysmon.service

7. 攻击者基础设施

• TeamPCP（与之前 Trivy、KICS 攻击高度重叠）：相同 RSA 密钥、相同 tpcp.tar.gz 文件名、相同 C2 域名模式、相同 systemd 服务名。
• Exfil 域名：1.82.7：

1. 主要用 checkmarx.zone
2. 1.82.8：新增 models.litellm.cloud（模仿合法域名）

攻击来源：很可能通过之前 Trivy 妥协窃取了 LiteLLM 的 PyPI 发布凭证（或 maintainer GitHub token），绕过正常 GitHub release 流程，直接上传 wheel 到 PyPI。

4. IOC（Indicators of Compromise）

恶意文件：

• litellm_init.pth（SHA256: ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg 等）
• litellm/proxy/proxy_server.py 中异常的 base64 块

持久化路径：

• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service

C2 / Exfil：

• models.litellm.cloud
• checkmarx.zone/raw

K8s 异常：

• kube-system 命名空间下 node-setup-* pod

进程：临时 /tmp/pglog 或大量 Python 子进程

安全版本：1.82.6 是已知最后一个干净版本。

结束语

LiteLLM 1.82.7 和 1.82.8 后门事件，是 2026 年供应链攻击浪潮中又一次高调的警钟。TeamPCP 通过精心设计的多阶段 payload（凭证窃取 + Kubernetes 横向移动 + systemd 持久化后门），在短短几小时内就对数以百万计的 AI 项目、开发环境和生产集群构成了严重威胁。尤其是 1.82.8 引入的 litellm_init.pth 零点击执行机制，让恶意代码在任何 Python 进程启动时悄无声息地运行，其狡猾程度远超普通依赖注入攻击。这场攻击再次证明：即使是月下载量近亿的热门开源库，也可能在一夜之间成为攻击者的跳板。它不仅暴露了 PyPI 发布流程、CI/CD 工具（如 Trivy）和 maintainer 凭证的脆弱性，更凸显了 AI 生态中 LLM API keys、云凭证和 Kubernetes 集群的高度集中风险。

核心教训：

• 永远不要盲目信任 pip install 的最新版本；
• 必须严格 pin 依赖版本、使用 lock 文件，并定期进行依赖扫描；
• 一旦怀疑感染，立即假设所有凭证已泄露，并全面轮换（SSH、云账号、LLM keys 等）；
• 加强供应链安全：启用可信发布、双因素验证、SBOM 验证和运行时监控。

目前恶意版本已被 PyPI 移除，官方推荐回滚至 1.82.6 或更早的安全版本。安全社区（Endor Labs、JFrog、SafeDep 等）已公开大量 IOC 和分析，帮助大家快速检测与清理。供应链安全没有“绝对安全”，只有持续的警惕与最佳实践。希望这次事件能推动整个开源与 AI 社区进一步强化防御机制——因为下一次攻击，可能就在下一个热门库中。如果你还在使用 LiteLLM，或有任何环境需要进一步的检测/清理帮助，欢迎随时提供更多细节，我会继续协助。保护好你的凭证，保护好你的集群，安全第一。

END

公众号内容都来自国外平台-所有文章可通过点击阅读原文到达原文地址或参考地址

排版 编辑 | Ots 小安

采集 翻译 | Ots Ai牛马

公众号 | AnQuan7 (Ots安全)

免责声明：

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

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

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

本文转载自：Ots安全 《litellm 1.82.7 和 1.82.8 后门自查指南》