2026 年 3 月 24 日，LiteLLM 项目遭遇供应链攻击，两个恶意版本（v1.82.7 和 v1.82.8）被上传至 PyPI 并在约 5 小时内被分发给下游用户。本文以分钟级时间线还原事件响应全过程，为安全团队提供可复现的应急处置时序参考。

事件背景与关键时间窗口

LiteLLM 是一个流行的 AI 网关项目，在全球拥有超过十万的周活跃用户。攻击者通过入侵项目维护者的 PyPI 账号，在官方发布流程之外直接上传了包含恶意代码的版本。根据官方披露的信息，受影响版本的时间窗口为 2026 年 3 月 24 日 10:39 UTC 至 16:00 UTC，共计约 5 小时 21 分钟。

恶意代码的核心功能是凭证窃取：扫描受害主机的环境变量、SSH 密钥、云服务商凭证（AWS、GCP、Azure）、Kubernetes 令牌以及数据库密码，然后加密外传至攻击者控制的域名 models.litellm.cloud。值得注意的是，使用官方 Docker 镜像（ghcr.io/berriai/litellm）的用户未受波及，因为该部署路径在 requirements.txt 中锁定了依赖版本，不依赖 PyPI 直接安装。

分钟级响应时间线

以下时间线基于 LiteLLM 官方博客披露的信息整理，所有时间均采用 UTC 时区：

10:39 —— 攻击者上传首个恶意版本 litellm v1.82.7 至 PyPI。该版本在 proxy_server.py 中嵌入了凭证窃取 payload，开始向未授权域名 models.litellm.cloud 外传数据。

10:45 至 12:00 —— 恶意包通过 pip install litellm（未指定版本）开始在全球范围传播。此时间段内任何执行默认安装命令的开发者和 CI/CD 流水线均可能中招。

12:00 —— 攻击者上传第二个恶意版本 litellm v1.82.8。该版本增加了 litellm_init.pth 文件，用于在 Python 启动时自动执行恶意代码，进一步扩大攻击面。

12:44 —— 根据官方建议的扫描窗口，此时间为受影响 CI/CD 作业的最后截止点。社区随后开发了自动化扫描脚本，可在此时间窗口内检索 GitHub Actions 和 GitLab CI 作业日志，识别是否有人在此期间安装了问题版本。

14:00 —— LiteLLM 官方发布安全公告（Security Update: Suspected Supply Chain Incident），确认受影响版本为 v1.82.7 和 v1.82.8，并指出攻击源头疑似为 Trivy 安全扫描工具的依赖泄露导致 CI/CD 凭证被盗。官方同时将从 PyPI 移除这两个版本，暂停新版本发布，并启动与 Google Mandiant 安全团队的联合调查。

14:30 —— 安全公告发出后 30 分钟内，全球开发者社区开始响应。Slack 频道和 GitHub Issues 涌现大量关于凭证轮换和主机检查的讨论。

15:00 —— 官方提供初步检测指南：使用 pip show litellm 检查当前版本；使用 find 命令在 site-packages 中检索 litellm_init.pth 文件；审计外联流量至 models.litellm.cloud 域名的日志。

16:00 —— 官方定义的受影响窗口关闭。此后新安装的用户不会收到恶意版本。

3 月 25 日 —— 官方更新公告，添加社区贡献的 GitHub Actions 和 GitLab CI 自动化扫描脚本。这些脚本可遍历组织内所有仓库的流水线日志，精准定位在受影响时间窗口内安装了问题版本的 CI 作业，大幅降低排查成本。

响应过程的关键观察点

从上述时间线可以提炼出几个值得关注的要点。首先是 响应速度：官方在首个恶意包发布后约 3.5 小时（14:00）即发布公告，这个速度在供应链攻击场景中属于中等偏快。但从恶意包上线到大规模传播，中间存在约 1 小时的安全窗口，足够攻击者收集首批受害者的凭证。

其次是 攻击链的巧妙性：攻击者选择通过 Trivy（一个流行的开源安全扫描工具）的依赖入手，而非直接暴力破解 PyPI 账号。这种「攻破供应链上游工具」的策略极具隐蔽性，因为开发者通常信任安全扫描工具的可靠性，不会对其输出进行额外审查。

第三是 Docker 用户的天然保护：官方指出使用 Docker 镜像的用户完全未受影响，这印证了「锁定依赖版本」作为供应链防御核心策略的有效性。所有生产环境应优先考虑镜像或锁定版本的方式部署，而非依赖运行时动态拉取最新包。

可落地的应急参数清单

基于本次事件的时间线特征，建议团队设定以下应急参数：

检测窗口阈值设定为事件公告后 6 小时内完成首次全员排查；受影响版本列表固定为 litellm==1.82.7 和 litellm==1.82.8；外联威胁域名锁定为 models.litellm.cloud（非官方域名）；文件系统 IOC 特征为存在 litellm_init.pth 文件；凭证轮换范围覆盖事件窗口内所有运行过受影响版本的服务器（包括 CI 节点）。

建议在 CI/CD 流水线中强制使用版本锁定（pip install litellm==1.82.6 或更新后的安全版本），并对所有依赖安全扫描工具的输出增设人工复核环节。

小结

LiteLLM 供应链攻击事件提供了一个完整的「攻击 — 发现 — 响应」闭环案例。从 10:39 的首个恶意包上线到 14:00 的官方公告，再到次日社区扫描脚本的发布，事件响应在每个关键节点都留有可追溯的时间戳。安全团队可将本文的时间线作为参考模板，建立自身供应链安全的分钟级响应预案。

资料来源：LiteLLM 官方安全公告（docs.litellm.ai/blog/security-update-march-2026）