如果你最近在用 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 等）的底层枢纽。
另外，在很多企业架构里，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 已经无法直接下载到这两个高危版本，从源头上阻断了恶意软件的进一步传播。
由于恶意脚本利用 .pth 文件实现了 " 静默启动 " 和 " 自我复制 "，单纯的官方删包无法清除已经潜入你电脑里的毒素。
因此，当前最紧要的操作是立即手动检查本地环境版本，确保回滚至安全的 v1.82.6。
那么此后这种投毒还可能再度发生吗？要是 OpenClaw 的 skill 里也被人用类似的方法投毒呢？或者触发条件更低一点：要是 OpenClaw 的 skill 里就调用了某个被投毒的库呢？
会，而且很可能不止一次。
因为攻击成本太低，而收益太高。一行恶意代码，只要混进一个高频依赖，就可能影响成千上万的项目；而防守方，却要为每一层依赖付出审计成本。这本质上是一场长期的不对称博弈。
如果指望一个 " 一劳永逸 " 的根治方案，现实一点说：没有。
这类像 LiteLLM 这样的供应链投毒，本质不是某个漏洞，而是一整套软件生产方式带来的系统性风险。只要现代开发还依赖海量第三方库、还在用 pip install 这种 " 默认信任 " 的分发机制，这个问题就不可能被彻底消灭。
而虽说它无法被根治，但可以被大幅压缩到可控范围内。
从行业趋势来看，已经有几个很明确的方向在形成。就比如在像 OpenClaw 这样的新一代 AI Agent 框架上，已经开始呈现多层防御的思路。
OpenClaw 的 3.22 最新版本，已经逐步引入沙箱隔离、权限收缩和运行时审计等机制：高风险操作被限制在独立环境中执行，敏感环境变量被主动屏蔽，子代理运行在隔离沙箱内，避免直接接触主系统资源，同时还增加了检测异常行为的审计能力。
同时，围绕 OpenClaw 的实践也在快速演进。越来越多开发者开始默认开启沙箱模式、用 Docker 做运行隔离、执行最小权限原则，并对 API Key 做定期轮换，而不是像过去那样，把高权限凭证直接暴露给整个 Agent 运行环境。
总的来说，对开发者而言，需要把 " 默认信任 " 切换为 " 默认怀疑 "；而对普通用户来说，与其追逐功能的丰富和接入的速度，不如把选择权交给那些真正愿意为安全付出成本的平台。
因为在这个阶段，决定体验上限的，也许是功能，但决定风险下限的，只能是安全。
本文来自微信公众号：字母 AI，作者：刘奕君
