担心的事还是发生了，真有人给龙虾“投毒”

文 | 字母AI

如果你最近在用OpenClaw跑Agent、装Skill，或者即便只是正常装了几个常见依赖，那你可得好好注意了！

今日，资深开发者Daniel Hnyk在社交平台X上紧急发文警告称：LiteLLM的PyPI官方发布版本1.82.8已被注入恶意代码，并着重强调“DONOTUPDATE”（请勿更新）。

随后OpenAI联合创始人、前特斯拉AI主管Andrej Karpathy也亲自发帖称：“软件恐怖事件：litellm PyPI供应链攻击。”

不要认为LiteLLM被投毒和OpenClaw没有任何关系。

即使你没有主动安装LiteLLM，只要你用于OpenClaw的某个Skill或组件依赖了它，它就已经在你的项目里运行了。

这就是所谓的依赖链：你依赖一个工具，这个工具再依赖另一个库，而那个库再依赖更多东西。只要其中一环被投毒，风险就会顺着整条链条传导下来。

而且一旦某个底层依赖库被投毒，最麻烦的地方在于，你几乎没有任何体感。你不会看到报错，也不会收到提示，一切看起来都在正常运行，但在某一层你看不到的依赖深处，敏感信息可能已经被悄悄带走。

投毒破坏力从何而来？

在了解可能的风险之前，我们先来说说LiteLLM是什么。

LiteLLM是大模型生态中几乎人手必备的关键适配层，其地位如同AI开发界的通用翻译官。

在GitHub上，该项目（BerriAI/litellm）已斩获超4万颗星，月下载量高达9700万次，是连接开发者与上百个LLM（如OpenAI、Anthropic、GoogleVertex等）的底层枢纽。

它的核心价值在于将复杂的各家API统一为OpenAI标准格式，使得开发者只需写一套代码就能无缝切换模型。

另外，在很多企业架构里，LiteLLM不仅仅是一个库，更是作为“AI网关”管理着全公司的模型调用权限与成本追踪。

正因为LiteLLM处于这种咽喉要道的位置，此次供应链投毒事故的破坏力呈指数级放大。

攻击者在官方仓库发布的恶意版本（1.82.7和1.82.8）利用了Python极高权限的初始化机制，这意味着只要执行pip install，恶意代码就会像病毒一样静默潜伏。

由于LiteLLM的主要职能就是处理API密钥，它成了窃取凭证的最佳跳板：从OpenAI密钥到AWS/Azure云端密钥，再到SSH访问权限甚至Kubernetes集群配置，所有核心数字资产都在黑客的洗劫范围内。

Andrej Karpathy的帖文中也提到了这一点：“只需一条简单的pip install litellm命令，就可能导致SSH密钥、AWS/GCP/Azure凭证、Kubernetes配置、Git凭证、环境变量（包含你所有的API密钥）、Shell历史记录、加密钱包、SSL私钥、CI/CD密钥、数据库密码等敏感信息被窃取。”

这不仅意味着数据可能在我们这种普通用户毫无察觉的情况下，被第三方截取甚至被长期监控，它更可能导致成千上万基于LiteLLM构建的企业级AI应用、自动化工作流及其背后的云端基础设施面临集体破防风险。

投毒是怎么发生的？

那么投毒是怎么发生的，又是怎么被发现的？

攻击的起点并非LiteLLM的代码漏洞，而是人的漏洞。黑客组织通过凭证窃取或社交工程手段，非法获取了LiteLLM维护者的PyPI（Python官方包索引）账号权限。

相当于黑客获得了通行证，可以直接在官方渠道发布任何他们想要的代码。

之后阴险的地方在于，黑客并没有修改LiteLLM原有的复杂逻辑代码，因为大规模的代码变动很容易在自动化扫描或人工审查中露出马脚。

相反，他们利用了Python环境中一个极具隐蔽性的特性，即在软件包中塞入了一个名为litellm_init.pth的文件。

这种以.pth结尾的文件原本是用来在解释器启动时自动配置路径的，因此它在site-packages目录中拥有极高的执行优先级。

这意味着，只要你的开发环境中安装了这个恶意版本，哪怕你的代码里完全没有写过import litellm，只要你启动Python解释器运行任何程序，这段恶意代码就会被立刻唤醒。

为了进一步躲避安全软件的实时监测，黑客将攻击指令隐藏在了看似乱码的Base64编码字符串中。一旦恶意脚本随系统启动，它就会疯狂扫描宿主机中的环境变量和配置文件。

从最核心的OpenAI或Anthropic API密钥，到AWS、Azure等云端服务凭证，甚至是SSH访问密钥和Kubernetes集群配置，所有能证明你数字身份的资产都在其洗劫范围之内。

整件事最有意思的部分在于，这场堪称完美的投毒攻击，社区只花一个小时内就将其揭发，核心原因在于黑客的编程水平过低。

攻击者编写的恶意代码存在严重的内存泄漏问题，典型的“vibe coding”产生的Bug。

当一位名为Callum McMahon的开发者在Cursor编辑器中使用相关插件时，恶意代码直接把系统内存吃满导致宕机。这种动静立刻引起了技术大牛们的警觉，顺藤摸瓜抓住了这个刚上线不到一小时的毒包。

这也是为什么Andrej Karpathy会感到后怕：如果黑客的代码写得更优雅一点、资源占用更低一点，这颗毒药可能会在成千上万台服务器里静默潜伏数月，直到把全球AI公司的API Key和云端资产搬空。

要是被投毒，我们的龙虾还有救吗？

根据最新的进展，此次LiteLLM供应链攻击事件已进入清理与止损阶段。从官方团队发布的更新信息来看，PyPI仓库中被黑客植入恶意代码的污染版本v1.82.7和v1.82.8已被正式删除。

这意味着，开发者现在通过pip install已经无法直接下载到这两个高危版本，从源头上阻断了恶意软件的进一步传播。

然而，官方的删除动作并不意味着受影响的开发者可以高枕无忧。如果你的本地环境或生产服务器在过去24小时内执行过更新，且目前仍停留在上述两个版本，威胁依然存在。

由于恶意脚本利用.pth文件实现了“静默启动”和“自我复制”，单纯的官方删包无法清除已经潜入你电脑里的毒素。

因此，当前最紧要的操作是立即手动检查本地环境版本，确保回滚至安全的v1.82.6。

那么此后这种投毒还可能再度发生吗？要是OpenClaw的skill里也被人用类似的方法投毒呢？或者触发条件更低一点：要是OpenClaw的skill里就调用了某个被投毒的库呢？

会，而且很可能不止一次。

因为攻击成本太低，而收益太高。一行恶意代码，只要混进一个高频依赖，就可能影响成千上万的项目；而防守方，却要为每一层依赖付出审计成本。这本质上是一场长期的不对称博弈。

如果指望一个“一劳永逸”的根治方案，现实一点说：没有。

这类像LiteLLM 这样的供应链投毒，本质不是某个漏洞，而是一整套软件生产方式带来的系统性风险。只要现代开发还依赖海量第三方库、还在用pip install 这种“默认信任”的分发机制，这个问题就不可能被彻底消灭。

而虽说它无法被根治，但可以被大幅压缩到可控范围内。

从行业趋势来看，已经有几个很明确的方向在形成。就比如在像 OpenClaw 这样的新一代AI Agent框架上，已经开始呈现多层防御的思路。

OpenClaw的3.22最新版本，已经逐步引入沙箱隔离、权限收缩和运行时审计等机制：高风险操作被限制在独立环境中执行，敏感环境变量被主动屏蔽，子代理运行在隔离沙箱内，避免直接接触主系统资源，同时还增加了检测异常行为的审计能力。

同时，围绕 OpenClaw的实践也在快速演进。越来越多开发者开始默认开启沙箱模式、用 Docker做运行隔离、执行最小权限原则，并对API Key做定期轮换，而不是像过去那样，把高权限凭证直接暴露给整个Agent运行环境。

总的来说，对开发者而言，需要把“默认信任”切换为“默认怀疑”；而对普通用户来说，与其追逐功能的丰富和接入的速度，不如把选择权交给那些真正愿意为安全付出成本的平台。

因为在这个阶段，决定体验上限的，也许是功能，但决定风险下限的，只能是安全。