月下载 9700 万的 Python 库被“投毒”

作者：GC随笔

⚠️ 重要提醒：如果你最近用过 pip install litellm，请立刻行动！这次攻击，不是“可能”，是“极可能”已入侵你的环境！

🚨 一场无声的“数字劫难”：从一句 pip install 开始

所有人都以为，pip install 是最安全、最简单的命令。

但就在 2024 年 3 月 24 日上午 10:52（UTC），这个看似无害的指令，差点引爆一场席卷整个开源生态的供应链安全灾难。

罪魁祸首，是那个你可能每天都在用的库——LiteLLM。

🧩 LiteLLM 是什么？为什么它这么“危险”？

简单说，LiteLLM 就是一个“AI 模型万能适配器”。

它让你能用同一套代码，无缝切换调用 OpenAI、Anthropic、Google、Azure、通义千问等各大模型，实现“换模型不改代码”。

📊 数据说话：

• 月下载量：9700 万次（相当于每分钟约 700 人次）
• 被 DSPy、Cursor、LangChain 等主流 AI 工具依赖
• 是当前 AI 开发圈的“基础设施”级库

✨ 一句话：你随便写个 AI 项目，可能就间接用了它。

🧨 投毒来了：一夜之间，“无中生有”两个恶意版本

令人震惊的是：

• 1.82.7与 1.82.8 两个版本，被恶意注入了后门代码
• 它们出现在 PyPI 上，但 GitHub 仓库没有对应的 release 或 tag
• 说明：这个发布是绕过正常流程的“非法发布”，纯属“影子提交”

🚫 这种操作极其罕见，也极为危险——攻击者直接绕过了开源协作的审核机制。

🕵️ 核心武器：一个“隐形”的 .pth 文件

攻击者藏了一枚“定时炸弹”——一个名为 .pth 的文件。

🔍 什么是 .pth 文件？

它是 Python 的路径配置文件，在解释器启动时自动执行代码，且无需你主动调用。

📌 一旦你安装了恶意版本，只要运行 Python，攻击代码就已悄悄执行！

😨 攻击链全解密：三步走，夺取你的数字世界

这次攻击设计极为精巧，分为三个阶段：

🔍 第一步：收集机密信息

恶意代码会主动扫描你的系统，搜刮所有敏感数据：

• SSH 私钥与配置
• .env
   文件中的 API Key
• AWS/GCP/Azure 云平台凭证
• Kubernetes 配置文件
• Git 凭证、数据库密码
• Shell 历史记录
• 甚至加密货币钱包（如 Bitcoin、MetaMask）

📤 第二步：加密外传

窃取的数据不会明文发送，而是：

• 使用 AES-256-CBC 加密
• 会话密钥使用 4096 位 RSA 公钥加密
• 打包成 tar 文件，发送至虚假域名：https://models.litellm.cloud/

⚠️ 关键点：这个域名不属于 LiteLLM 官方基础设施，纯属伪造！

💀 第三步：横向扩散，接管集群

如果检测到你是 Kubernetes 环境：

• 读取所有 namespace 的 Secrets
• 在每个节点创建特权 Pod
• 挂载宿主机文件系统
• 写入后门脚本：/root/.config/sysmon/sysmon.py
• 注册 systemd 服务，实现永久控制

💥 结果：你的服务器，可能早已被“黑掉”，你却毫不知情。

🛑 巧妙“翻车”：攻击者自己写 Bug，才暴露了自己

最讽刺的一幕来了👇

最初发现问题的，是 FutureSearch 团队的工程师 Callum McMahon。

他在测试 Cursor MCP 插件时，发现：

Python 一启动，机器就卡死，内存被瞬间耗尽！

经过深入分析，发现是 LiteLLM 包中包含一个 34KB 的 .pth 文件，内容经过双重 base64 编码。

更致命的是：
这个恶意代码会启动一个子 Python 进程，而子进程又会触发 .pth 的执行……
形成无限递归，最终触发“fork 炸弹”效应。

🤯 系统内存指数级增长 → 机器彻底崩溃。

✅ 本该是“无声入侵”的攻击，偏偏因为自己代码写得太烂，反把自己 “炸”了出来。

🧠 专家点评：这是一次“几乎完美”的攻击

AI 领域大神 Andrej Karpathy 在 X 上写道：

“如果攻击者不是用 Vibe Code 写代码（而是有 Bug），这次攻击很可能潜伏数天甚至数周。”

言下之意：
这次没被发现，是运气，不是防御强。

🛡️ 你现在该怎么做？立即行动！

如果你在 2024 年 3 月 24 日之后安装过 LiteLLM，请立即执行以下操作：

例如港大开源的nanobot也是用到了litellm,可以让他自查。

✅ 1. 检查是否中招

pip show litellm

重点关注是否为 1.82.7 或 1.82.8。

✅ 2. 清理缓存 & 环境

pip cache purge
rm -rf ~/.cache/uv

👉 建议删除所有虚拟环境中的 litellm 包。

✅ 3. 检查后门文件

重点排查以下路径是否存在异常文件：

• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service
• ~/.cache/pip/wheels/
   中是否含有异常包

Kubernetes 用户额外检查：是否有可疑 Pod（如 node-setup-*）？

✅ 4. 最关键！立即更换所有凭证！

⚠️ 无论你是否主动使用 LiteLLM，只要装过，所有敏感凭据一律视为已泄露！

包括：

• SSH Key
• 云服务 API Key（AWS、GCP、Azure）
• Kubernetes 配置
• 数据库密码
• Git 密钥
• 微信/支付宝等平台的 API Key

📌 一条原则：一旦你装过 1.82.7/1.82.8，就当“全系统清零”处理。

💡 写在最后：我们是否该重新思考“依赖”？

这次事件给整个开发者社区敲响了警钟：

🌲 现代软件早已建立在“依赖森林”之上。一个库的漏洞，可能通过依赖链传播到成千上万的项目。

更可怕的是：
一旦攻击者拿到你的凭证，他可以：

• 登录你的云服务器
• 篡改你的代码仓库
• 发布新的恶意版本
• 形成“自我复制”的攻击闭环

🔐 Karpathy 的一句警告直击人心：

“在某些简单场景下，我宁愿让大模型直接生成代码，也不愿引入一个不可控的依赖。”

这句话说得极端，却有深刻道理：

可控的代码，比不可控的依赖，更安全。

📣 最后提醒：

• 🚩 当前 1.82.7/1.82.8 已被 PyPI 下架
• 🚩 无大规模数据泄露报告，算不幸中的万幸
• 🚩 但你永远不能确定：是否已中招 → 所以，行动！立刻！马上！

🔐 安全不是“防得住”就万事大吉，而是“一旦中招，能快速止损”。

这次事件也提醒我们：

在开源生态的“信任”之外，我们更需要“验证”与“警惕”。

📌 转发本文，提醒更多开发者朋友，保护好你的机密与代码！
💬 欢迎在评论区留言：你是否也曾“中过招”？欢迎分享你的应急经验！

📎 关注我们，获取更多：AI 安全、开源治理、DevSecOps 实战干货。
🔗 技术干货 + 一手预警，就在这儿！