PyPI遭投毒：个人凭证秒泄量子位

Python 程序员小心了！

PyPI 又双叒叕被投毒 ——

最新上传的 LiteLLM Python 版本 1.82.7 和 1.82.8，已被人为恶意植入信息窃取程序。

一旦安装，SSH 密钥、AWS 凭证和 API 密钥等数据均会立即泄漏。

目前 LiteLLM 的维护者 Krrish Dholakia，已经公开证实此事。

在恶意版本存在三小时后，PyPI 迅速发现了这一漏洞，并将软件包隔离。但 LiteLLM 每天下载量约为 340 万次，许多自动安装新版本的程序员已经遭殃。

社区迅速引起热议，卡帕西也出面提醒，让程序员小心 LiteLLM 供应链攻击。

值得注意的是，即使没有手动安装过 LiteLLM，但你的电脑上可能也有它。

比如 OpenClaw 就会调用该库……

那么已经不慎中招的你，应该做的是 ——

发生了什么？

具体事情经过是这样的：

LiteLLM 是一个开源的 Python 库，它提供了一个统一接口，可以使用标准的 OpenAI 输入 / 输出格式调用 100 多个 LLM（OpenAI、Anthropic、VertexAI 等）。

每月下载量高达 9700 万次，GitHub 超 4 万星，也是人工智能开发领域安装量最高的 Python 包之一。

3 月 24 日，LiteLLM 1.82.8 版本被发布到 PyPI，其中包含一个名为 litellm_init.pth 的恶意文件。该文件会在 LiteLLM 安装完成后，无需主动调用该库，只要 Python 进程启动就会自动执行。

而此前的 1.82.7 版本也被同样证实存在相同的安全漏洞。

该漏洞是被 FutureSearch 的 Callum McMahon 第一时间发现的，当时他正在测试一个 Cursor MCP 插件，该插件引入了 LiteLLM。

但是在 Python 启动后不久，他的机器就因内存耗尽而停止响应。于是他追踪问题，一路查到了新安装的 LiteLLM 包上，并在目录下找到了 litellm_init.pth 文件。

该文件大小为 34628 字节，并经过双重 base64 编码，其中一个 base64 编码的有效载荷会负责窃取信息并持久存在于受影响的机器上。

它将通过三个阶段对用户信息进行盗取：

Python 脚本将会从主机上收集用户的各种敏感文件，包括 SSH 私钥和配置文件、AWS/GCP/Azure 凭证、Kubernetes 配置、数据库密码等。它还会运行命令来导出环境变量并查询云元数据端点（IMDS、容器凭证）。

2、数据外泄：

收集到的数据将会使用硬编码的 4096 位 RSA 公钥，通过 AES-256-CBC 进行加密，打包成 tar 归档文件，并通过 POST 请求发送到一个不属于 LiteLLM 的攻击者云端。

3、横向扩散：

如果检测到用户存在 Kubernetes 服务帐户 token，恶意软件会读取所有命名空间中的所有集群密钥，并尝试在每个节点上创建一个具有特权的 pod。每个 pod 都会挂载主机文件系统，并安装一个带有 systemd 用户服务的持久化后门。

根据 LiteLLM 的维护者 Krrish Dholakia 描述，这一漏洞源自于项目管道中使用的安全工具 Trivy。

攻击者通过篡改 Trivy 的 GitHub Action，向其注入恶意窃取代码，并连续攻击 Checkmarx KICS 和 Aqua Security 仓库。

随后，LiteLLM 的 CI/CD 在构建过程中接触到了被污染的 Trivy，并让攻击者窃取到了维护者的 PyPI 凭证。利用该凭证，攻击者先后发布恶意版本 LiteLLM 1.82.7 和 LiteLLM 1.82.8。

用户只要正常下载就会中招，期间不会产生任何异常提示。其中 1.82.7 的恶意代码需要用户运行 LiteLLM 时触发，1.82.8 则只要用户启动 Python 就会执行窃取程序。

目前受影响的版本已经被撤回，PyPI 也已解除对 LiteLLM 的隔离，维护者目前正在处理后续事宜，预计将审查所有 Berriai 代码库的影响，以及整体扫描 CI 情况并减轻其作用。

紧急自检与修复流程

但如果是那些在过去 24 小时内有安装 LiteLLM 新版本的程序员，就需要额外注意了，其系统可能已经被入侵，以下是自检流程：

Step 1：检查已安装的版本

pip show litellm | grep Version

同时在 uv 缓存和 CI/CD 虚拟环境中搜索 litellm_init.pth。如果输出版本号为 1.82.7 或 1.82.8，则表明系统已被植入恶意程序，需要执行修复步骤，切勿进行直接升级。

Step 2：移除软件包并清除缓存

用户需立即从所有受影响的环境中删除版本，并使用命令行清除软件包管理器缓存，以防止从缓存的 wheel 文件重新安装。

rm -rf ~/.cache/uv

或者pip cache purge

Step 3：检查持久化工件

~/.config/sysmon/sysmon.py

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

如果运行在 Kubernetes 中，需要审核 kube-system 是否存在匹配 node-setup-* 的 Pod，并检查集群密钥是否存在未经授权的访问。

Step 4：切换个人凭证

将个人的所有凭证全部进行更换，以绝后患。

至于还尚未安装 1.82.7 或 1.82.8 版本的程序员，可以先暂时锁定 1.82.6 版本，等到安全的新版本发布。