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 编码的有效载荷会负责窃取信息并持久存在于受影响的机器上。
它将通过三个阶段对用户信息进行盗取：
1、收集：
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 版本，等到安全的新版本发布。
供应链攻击将常态化
而这并非偶发事件，近段时间以来，有关供应链的攻击已经成规模化，而且更多地集中在自动化流水线里那些拥有高权限的工具上，比如 Trivy、KICS、LiteLLM。
这些工具从设计之初，就拥有广泛的读取权限，一旦被入侵，所泄漏的数据规模也比一般应用程序要广得多。
而且这类供应链攻击的影响范围也会更大，即使是用户没有直接安装恶意程序，只要依赖的底层工具依赖它，同样也会被影响。
尤其是对于那些拥有大量依赖项的大型项目而言，风险非常之高。
反观开发者们，在此之前也通常会忽略这类依赖，很少检查深层工具的安全性，对安装新版本的警惕性不够，所以这件事也为广大程序员朋友们敲醒了警钟。
卡帕西也提醒各位：
传统的软件工程会让你相信依赖关系是好事，就像用砖块建造金字塔，但我认为这需要重新评估，这也是我越来越反感依赖关系的原因，我更喜欢在足够简单和可行的情况下使用 LLM 来"窃取"功能。
《从零开始构建大模型》一书的作者Sebastian Raschka也表示，几年前 PyPI 也发生过类似的"投毒"事件，最好的办法是将源代码保留在自己的库中。
也有部分网友表示，未来类似的供应链攻击将成为新常态，针对开发工具的供应链安全需要尽快提上日程。
同时有网友认为，本次泄漏问题能够被及时发现，是 Vibe Coding 救了我们。
如果攻击者编写的代码更简洁，那么该程序就可以在数百万台机器上悄无声息地运行数天甚至数周。
参考链接：
[ 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
一键关注 � � 点亮星标
科技前沿进展每日见
盛达优配提示：文章来自网络，不代表本站观点。
