Python 程序员小心了！PyPI又双叒叕被投毒——
最新上传的LiteLLM Python 版本 1.82.7 和 1.82.8，已被人为恶意植入信息窃取程序。
一旦安装，SSH 密钥、AWS 凭证和 API 密钥等数据均会立即泄漏。
目前 LiteLLM 的维护者 Krrish Dholakia，已经公开证实此事。
社区迅速引起热议，卡帕西也出面提醒，让程序员小心 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 编码的有效载荷会负责窃取信息并持久存在于受影响的机器上。
它将通过三个阶段对用户信息进行盗取：
1、收集：
Python 脚本将会从主机上收集用户的各种敏感文件，包括 SSH 私钥和配置文件、 AWS/GCP/Azure 凭证、Kubernetes 配置、数据库密码等。它还会运行命令来导出环境变量并查询云元数据端点（IMDS、容器凭证）。
收集到的数据将会使用硬编码的 4096 位 RSA 公钥，通过 AES-256-CBC 进行加密，打包成 tar 归档文件，并通过 POST 请求发送到一个不属于 LiteLLM 的攻击者云端。
如果检测到用户存在 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 情况并减轻其作用。
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 版本，等到安全的新版本发布。
而这并非偶发事件，近段时间以来，有关供应链的攻击已经成规模化，而且更多地集中在自动化流水线里那些拥有高权限的工具上，比如 Trivy、KICS、LiteLLM。
这些工具从设计之初，就拥有广泛的读取权限，一旦被入侵，所泄漏的数据规模也比一般应用程序要广得多。
而且这类供应链攻击的影响范围也会更大，即使是用户没有直接安装恶意程序，只要依赖的底层工具依赖它，同样也会被影响。
尤其是对于那些拥有大量依赖项的大型项目而言，风险非常之高。
反观开发者们，在此之前也通常会忽略这类依赖，很少检查深层工具的安全性，对安装新版本的警惕性不够，所以这件事也为广大程序员朋友们敲醒了警钟。
卡帕西也提醒各位：
传统的软件工程会让你相信依赖关系是好事，就像用砖块建造金字塔，但我认为这需要重新评估，这也是我越来越反感依赖关系的原因，我更喜欢在足够简单和可行的情况下使用 LLM 来 " 窃取 " 功能。
如果攻击者编写的代码更简洁，那么该程序就可以在数百万台机器上悄无声息地运行数天甚至数周。
[ 1 ] https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
[ 2 ] https://x.com/KanikaBK/status/2036502940031328266
[ 3 ] https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/
[ 4 ] https://x.com/i/trending/2036436459386024371
一键三连「点赞」「转发」「小心心」
欢迎在评论区留下你的想法！
— 完 —
当龙虾火得一塌糊涂之时，会成为AI 初创全球化的新机会吗？
周四 14 点，不论你是已经出海、正在筹备，还是只想搞懂全球 AI 创业的真实逻辑，欢迎来现场交流 https://hdxu.cn/1G4KS
科技前沿进展每日见
