刚刚，9700 万下载量的 litellm 被投毒了——作为贡献者，我来聊聊这件事

作为 litellm 的活跃贡献者和 LLM 安全工具作者，我来聊聊昨天这起影响深远的供应链攻击。

发生了什么

2026 年 3 月 24 日，PyPI 上的 litellm 1.82.7 和 1.82.8 版本被发现包含恶意代码。攻击者在包中植入了一个 litellm_init.pth 文件——这是 Python 的一个冷门机制，.pth 文件会在每个 Python 进程启动时自动执行，无需任何 import 。

这段恶意代码会静默窃取：

• SSH 密钥（~/.ssh/）
• AWS 、GCP 、Azure 云凭证
• Kubernetes 配置
• 环境变量（包含各种 API Key ）
• 加密货币钱包
• 数据库密码

讽刺的是，这次攻击被发现的原因不是安全审计，而是恶意代码本身有 bug——它触发了 fork bomb ，直接把一个开发者的机器搞崩了。如果攻击者的代码质量再高一点，这个后门可能会安静地运行很久。

溯源：安全工具反成攻击入口

根因追溯到 3 月 19 日，安全扫描工具 Trivy 被攻击组织 TeamPCP 入侵。litellm 的 CI/CD 流水线中使用了 Trivy 做安全扫描，攻击者通过被污染的 Trivy 获取了 litellm 的 PyPI 发布 token ，进而向 PyPI 推送了带后门的版本。

一个安全扫描工具，本应是防线的一环，却成了攻击的入口。这大概是整个事件中最值得深思的部分。

影响范围

litellm 是 AI/LLM 领域的核心基础设施之一，月下载量达 9700 万次，超过 2000 个包依赖它，包括 DSPy 、MLflow 、Open Interpreter 等知名项目。任何在 3 月 24 日前后通过 pip install litellm 安装或更新的开发者，都可能中招。

更恶劣的是，当社区在 GitHub Issues 中讨论此事时，攻击者动用了 73 个被盗账号，在 102 秒内发了 88 条垃圾评论，试图压制安全警告信息。Karpathy 也在 X 上发帖讨论了此事，引发了广泛关注。

我的视角：从 litellm 贡献者到安全工具作者

说一点个人背景。我目前是 litellm 的活跃贡献者，有 3 个安全相关的 PR 正在 review 中（#24346、#24455、#24458）。同时我也是 llm-seclint 的作者——一个专门为 LLM 应用设计的静态安全扫描工具。

在这次供应链攻击发生之前，我就用 llm-seclint 扫描过 litellm 的代码库，发现了真实存在的安全漏洞：exec() 导致的远程代码执行（ RCE ）风险，以及 Jinja2 模板注入（ SSTI ）。这些都是代码层面的安全缺陷，静态分析可以有效捕获。

但这次供应链攻击给了我一个清醒的认识：静态分析能抓住代码级别的漏洞，却无法防御供应链攻击。恶意代码不是通过代码审查进入仓库的，而是在构建发布环节被注入。当你的 CI/CD 工具链本身被攻破时，代码写得再安全也没用。

这正是我构建 llm-seclint 的初衷——让 LLM 应用的代码安全有一道基本防线。但这次事件也让我更加确信：安全需要纵深防御，单一手段不够。静态分析、依赖审计、发布流水线加固、运行时监控，每一层都不可或缺。

你现在该做什么

如果你的项目直接或间接依赖 litellm ，请立即：

1. 检查版本：确认你没有安装 1.82.7 或 1.82.8 。运行 pip show litellm 查看当前版本。
2. 轮换凭证：如果你曾安装过受影响版本，假设所有凭证已泄露。轮换 SSH 密钥、云服务凭证、API Key 、数据库密码。
3. 锁定依赖版本：在 requirements.txt 或 pyproject.toml 中使用精确版本号（==），不要用 >=。搭配 hash 校验更好。
4. 审计 CI/CD 流水线：检查你的构建流程中使用的所有第三方工具，评估它们被入侵后的影响范围。
5. 检查 .pth 文件：在你的 Python site-packages 目录中搜索可疑的 .pth 文件——这是一个容易被忽视的攻击面。

更深层的思考

Karpathy 在 X 上评论此事时提到了依赖最小化的理念。这个观点值得认真对待。现代 Python AI 项目动辄上百个依赖，每一个都是潜在的攻击面。litellm 本身支持 100+ 个 LLM provider ，依赖树庞大，这既是它的价值，也是它的风险。

但”减少依赖”说起来容易，做起来是另一回事。litellm 之所以有 9700 万月下载量，正是因为它解决了一个真实的痛点。真正的答案不是不用依赖，而是建立对依赖的安全治理体系：签名验证、可重现构建、最小权限的 CI/CD token 、发布流程的多人审批。

这次事件也再次说明，AI 基础设施正在成为高价值攻击目标。当你的 LLM proxy 被投毒，泄露的不只是代码——而是你所有模型调用的 API Key 、用户数据、云基础设施的访问权限。AI 应用的安全面比传统应用更大，我们需要对应的安全工具和实践。

这是我持续关注 LLM 应用安全的原因，也是我在做 llm-seclint 和向 litellm 提交安全 PR 的动力。供应链攻击提醒我们：安全不是某一个工具或某一层防御能解决的问题，而是需要从代码、依赖、构建、运行时每一个环节去建设的系统工程。

如果你也在构建 LLM 应用，欢迎试试 llm-seclint 来扫描你的代码——它能帮你抓住代码层面的安全问题。至于供应链安全，我们整个社区都还有很长的路要走。