# LiteLLM 供应链攻击分钟级响应时间线：事件日志式复盘 > 以分钟级时间线记录2026年3月LiteLLM恶意代码攻击的完整事件响应过程，还原从发现到处置的关键时序节点。 ## 元数据 - 路径: /posts/2026/03/27/litellm-incident-response-minute-timeline/ - 发布时间: 2026-03-27T00:49:24+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 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） ## 同分类近期文章 ### [微软终止VeraCrypt账户：平台封禁下的供应链安全警示](/posts/2026/04/09/microsoft-terminates-veracrypt-account-platform-lock-risk/) - 日期: 2026-04-09T00:26:24+08:00 - 分类: [security](/categories/security/) - 摘要: 从VeraCrypt开发者账户被终止事件，分析Windows代码签名的技术依赖、平台封禁风险与开发者应对策略。 ### [GPU TEE 远程认证协议在机密 AI 推理中的工程实现与安全边界验证](/posts/2026/04/08/gpu-tee-remote-attestation-confidential-ai-inference/) - 日期: 2026-04-08T23:06:18+08:00 - 分类: [security](/categories/security/) - 摘要: 深入解析 GPU 可信执行环境的远程认证流程，提供机密 AI 推理场景下的工程参数配置与安全边界验证清单。 ### [VeraCrypt 1.26.x 加密算法演进与跨平台安全加固深度解析](/posts/2026/04/08/veracrypt-1-26-encryption-algorithm-improvements/) - 日期: 2026-04-08T22:02:47+08:00 - 分类: [security](/categories/security/) - 摘要: 深度解析 VeraCrypt 最新版本的核心加密算法改进、跨平台兼容性与安全加固工程实践，涵盖 Argon2id、BLAKE2s 及内存保护机制。 ### [AAA 游戏二进制混淆：自研加壳工具的工程现实与虚拟化保护参数](/posts/2026/04/08/binary-obfuscation-in-aaa-games/) - 日期: 2026-04-08T20:26:50+08:00 - 分类: [security](/categories/security/) - 摘要: 解析 AAA 级游戏二进制保护中的自研加壳工具、代码虚拟化性能开销与反调试实现的技术选型。 ### [将传统白帽黑客习惯引入氛围编程：构建 AI 生成代码的防御纵深](/posts/2026/04/08/old-hacker-habits-for-safer-vibecoding/) - 日期: 2026-04-08T20:03:42+08:00 - 分类: [security](/categories/security/) - 摘要: 将传统白帽黑客的安全实践应用于氛围编程，通过隔离环境、密钥管理与代码审计，为 AI 生成代码建立防御纵深，提供可落地的工程参数与清单。