2026年3月24日，AI开发者社区经历了一次堪称教科书级别的供应链攻击。当天上午，一个看似正常的版本更新 LiteLLM 1.82.8 出现在 PyPI 仓库中。
全球数百万开发者的终端每天都在自动拉取这类更新，几乎没人会留意到这个版本中暗藏了一段精心设计的恶意代码。一旦你执行了那句再普通不过的 pip install litellm，你机器上的 SSH 密钥、云服务凭证、数据库密码乃至加密货币钱包私钥，都可能在几秒内被加密打包，悄无声息地发送到攻击者控制的服务器。
如果你的机器恰好连接着 Kubernetes 集群，恶意代码还会尝试横向移动，在集群的每个节点上植入持久化后门。
LiteLLM 是当前 AI 应用开发中核心的中间件之一，用于统一调用 OpenAI、Anthropic 等各大语言模型的 API。它的开源包在全球拥有每月近 9700 万次的下载量。这一次，这根关键的“管道”差点被人从内部彻底凿穿。而整个生态逃过一劫的原因，竟纯属意外——攻击者自己写的恶意代码里有一个 bug，导致被感染的机器直接崩溃。如果没有这个漏洞，这次隐秘的“投毒”行动将不知会潜伏并扩散多久。
AI 领域的知名人物 Andrej Karpathy 在深夜发文，直言这是“软件惊魂”（Software horror）。
Karpathy 在推文中列出的“窃取清单”详尽得令人心惊：AWS/GCP/Azure 凭证、Kubernetes 配置、CI/CD 机密、数据库密码、SSH 密钥、Git 凭证、环境变量（包含所有 API 密钥）、Shell 历史记录、加密钱包文件、SSL 私钥等。
“惊魂”过后，Karpathy 说出了一句可能动摇整个行业开发范式的话：“我越来越抗拒依赖了。”
一句 pip install 引发的全面洗劫
这绝非普通的漏洞警告。只要你执行 pip install litellm，你的整台机器将瞬间对攻击者门户大开。根据安全分析，这次攻击的目标是对整台机器乃至整个集群进行“全面洗劫”。
攻击者的窃取范围几乎覆盖了开发者所有的核心资产：
- SSH 私钥和配置
- AWS/GCP/Azure 凭证
- Kubernetes 配置和 Token
.env 文件中的 API Key- Git 凭证
- 数据库密码
- Shell 历史记录
- SSL 私钥
- CI/CD 机密
- 加密货币钱包文件
- 环境变量中的所有敏感信息
更可怕的是，LiteLLM 并非冷门工具。作为连接各大语言模型提供商的关键中间件，它是名副其实的 AI 应用层“基础设施”，月下载量高达 9700 万次。许多项目用它来统一接入多家模型，众多 Agent 框架、MCP Server 和 LLM 编排工具也将其作为底层依赖。
这使得此次投毒的影响被急剧放大，整条 AI 依赖链都被撕开了一道口子。即使你从未直接使用过 LiteLLM，但只要你安装了依赖它的其他大型 AI 项目（例如执行 pip install dspy，其依赖 litellm>=1.64.0），你也会作为传递依赖的受害者中招。
一次投毒，顺着错综复杂的依赖树，瞬间就能辐射到无数 AI 项目中。这正是 Karpathy 将其定义为“软件界的恐怖故事”的原因。
因黑客“代码太烂”而暴露的史诗级漏洞
你或许会认为，影响如此巨大，安全公司应该第一时间就拉响了警报吧？但事实的真相颇具讽刺意味。
最早发现异常的，是 Callum McMahon 团队的工程师。
当时，他们在 AI 编码工具 Cursor 中使用一个 MCP 插件，而该插件将 LiteLLM 作为传递依赖引入了环境。安装被投毒的 LiteLLM 1.82.8 后，机器突然出现异常：内存被疯狂耗尽，最终直接崩溃。
经过排查，问题根源指向一个 .pth 文件。对于许多 Python 开发者而言，.pth 文件平时几乎没有存在感。但正是这个特性，使得它能够在 Python 解释器启动时自动执行代码。攻击者巧妙地将恶意启动器塞进了这里。
按原设计，这个启动器会悄悄拉起子进程，执行后续的窃密和外传逻辑。然而，攻击者写砸了。由于子进程本身也会再次触发同一个 .pth 文件，导致每个新进程都会无限制地创建新进程，形成指数级增长的 fork bomb，迅速榨干机器所有资源。
也就是说，这次影响深远的攻击之所以暴露，仅仅是因为攻击者自己的代码“玩脱了”，把自己搞崩溃了。如果不是这个乌龙 bug，如此隐蔽的后门极可能在网络中潜伏数周甚至数月而不被察觉。整个行业的安全防线，竟然倚仗于黑客写出了一个 bug，现有的安全检测机制在此刻形同虚设，这正是整件事最让人后怕之处。
一场精心策划的三段式供应链攻击
从攻击手法的精密程度来看，这是一场有组织、专业化的“供应链投毒”。
首先，攻击者疑似通过某种手段（可能与更大范围的凭证泄露事件有关）攻破了维护者的 PyPI 账户，绕过了官方的 CI/CD 发布流程，直接将带有后门的 v1.82.7 和 v1.82.8 版本强行上传至 PyPI 仓库。在 LiteLLM 的 GitHub 源码仓库中，甚至找不到对应的 tag 或 release 记录。
其次，攻击载荷的设计采用了专业的三段式架构：
- 第一阶段（协调器）：负责大范围信息收集。
- 第二阶段（收集器）：使用内置的 4096 位 RSA 公钥配合 AES-256-CBC 对窃取的数据进行高强度加密，并外传至伪装成官方的域名
models.litellm.cloud。
- 第三阶段（持久化）：最致命的环节。如果环境中存在 Kubernetes 凭证，它会尝试横向移动，读取集群所有命名空间下的 Secret，并在每个节点上创建特权 Pod，植入持久化的 C2（命令与控制）后门。
LiteLLM 1.82.8 的恶意 litellm_init.pth 文件在 Python 解释器启动时被自动触发，进而执行三阶段攻击载荷。
事件发生后，一个令人毛骨悚然的细节出现了：当社区成员试图在 GitHub issue 中讨论此事时，该 issue 被项目所有者以“not planned”（暂无计划）为由直接关闭，随后遭到数百个机器人账号刷屏淹没，试图稀释讨论。
这强烈暗示维护者的账号和开发环境已被攻击者全面接管，对方正在系统性地掩盖痕迹。目前，LiteLLM 官方已介入，怀疑此次事件与更大范围的供应链安全事件有关，并紧急联系了 Google Mandiant 安全团队进行取证。
幸运的是，使用固定版本号拉取的官方 Docker 镜像用户未受影响。但这套完整的 APT（高级持续性威胁）手法，已经宣告针对开源供应链的攻击进入了新的、更危险的阶段。
Karpathy 的“反依赖宣言”与 AI 开发范式反思
这场灾难正在促使硅谷的顶尖技术精英重新思考软件工程的底层逻辑。
传统的软件工程智慧教导我们“不要重复造轮子”，依赖是构建复杂系统的基石。但在此次事件后，Karpathy 在推文中提出了他的“反依赖宣言”：
“这也是为什么我越来越抗拒依赖，更倾向于在功能足够简单、而且确实可行的时候，直接用 LLM 去生成一段功能来用。”
从“依赖是砖石”到“依赖是潜在的定时炸弹”，这不仅仅是情绪宣泄，更可能预示着 AI 时代开发范式的重大转折。每一次执行 pip install，你都在依赖树那深不可测的某一环，引入了难以评估的未知风险。
当大模型已经强大到能够直接生成并替代许多第三方库的简单功能时，“减少非必要依赖”将不再仅仅是代码洁癖，而可能演变为核心的安全与架构策略。
更富讽刺意味的是，本次事件的发现者 Callum 之所以中招，恰恰是因为使用了 AI 编码工具 Cursor，并通过其 MCP 插件引入了 AI 中间件 LiteLLM。构建 AI 的工具链自身，竟然成了攻击者利用的最大攻击面。AI 在创造新范式的同时，也在催生前所未有的新型安全漏洞。
9700万次下载背后的深层信任危机
事件发生后，LiteLLM 官方迅速采取了一系列止血措施：下架受污染版本、轮换维护者凭证、建立新的授权维护者名单、联系安全团队进行取证分析，并提示用户排查受影响版本、寻找入侵指标（IoC）以及轮换所有可能泄露的凭证。
尽管这次事件因攻击者自身的 bug 而迅速暴露，受污染版本在发布不到一小时后便被撤回，但其揭示的深层问题令人不安。这次事件之所以没有演变成一场静默的、大规模灾难，依靠的不是成熟的安全防御体系或主动检测，而是因为黑客自己犯了错。
每月 9700 万的下载量，意味着整个行业每月都在进行 9700 万次“信任传递”。这次“投毒事件”暴露出，当前 AI 基础设施所依赖的开源供应链信任模型可能极其脆弱。
你以为你信任的是经过成千上万双眼睛审查的开源代码，但实际上，你最终信任的仅仅是：某个远方的包维护者没有丢失他的 PyPI 账号密码，他的个人电脑没有感染木马，他的整个开发环境是安全的。
这种系统性的安全风险，对于重度依赖开源生态的 AI 行业无疑是一记警钟。如果开发者和企业大量依赖 PyPI 等公共仓库，而整个基础设施的安全又仅仅寄托在“上游没有被黑”这一脆弱的假设上，那么类似事件的重演，或许只是时间问题。
LiteLLM 事件只是一个开始。它迫使整个社区必须直面那个最令人不安的问题：谁会是下一个被“投毒”的包？开发者社区，如云栈社区，也持续关注此类安全动态，并提醒广大开发者在享受开源便利的同时，务必提高安全意识，审慎评估依赖风险。
参考资料
- Andrej Karpathy 推文: https://x.com/karpathy/status/2036487306585268612
- LiteLLM 官方安全公告: https://docs.litellm.ai/blog/security-update-march-2026
- 第三方安全分析报告: https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/
发表于 2 小时前
|
查看: 2|
回复: 0
