LiteLLM 1.107.0供应链攻击窃取云凭据

资讯专家

事件概述
2026年10月21日，LiteLLM 1.107.0 在 PyPI 和 Docker Hub 遭遇供应链投毒。LiteLLM 是用于跨 LLM 提供商路由请求的开源代理，恶意包在线约 3 小时，估计下载量超过 49,000 次。PyPI 已移除恶意包，Docker Hub 相关标签和镜像变体被移除或重新指向干净制品。

入侵路径
LiteLLM 调查称，攻击者获取了其内部 LiteLLM 部署中一个命名不显眼、暴露在公网的用户账号的 GitHub CLI OAuth token。这些 token 可能由 Claude Code 在特定情况下写入响应体，进而可能被记录到 LiteLLM 日志中，攻击者可能从日志取得。目前仍不清楚攻击者如何访问该内部部署或横向移动；攻击者掌握三组开发者 GitHub CLI 凭据。攻击者利用凭据禁用分支保护、合并更改将 releaser 指向另一源仓库、运行被篡改的 GitHub workflow 指向相似仓库，随后签名并发布投毒制品。

恶意载荷行为
下载 LiteLLM 1.107.0 恶意版本的用户会感染信息窃取器和 RAT。载荷可能借助 AI 构建，并从 Berri-AI/litellm 提供，该仓库伪装成合法仓库 BerriAI/litellm。载荷释放三个文件到 site-packages 根目录，使 Python 解释器运行时即执行。首先加载窃取器，收集系统信息、浏览器凭据和 cookies、开发者凭据、环境变量、云密钥（AWS、GCP、Azure）、AI 工具 API key（Anthropic、GitHub Copilot、OpenAI 等）、SSH 私钥、shell 历史文件和 GPG 密钥。窃取数据加密后发送至 litellm[.]dev。Wiz 称攻击者在凭据外泄约 4.5 小时后开始滥用，并观察到使用盗取的 AWS 凭据查询 Amazon Bedrock 模型，提示存在 LLMjacking。RAT 会定期连接 C2，且 StepSecurity 称其每小时检查 GitHub dead drop 并运行攻击者提供的 Python。

影响与处置
从私有仓库拉取 LiteLLM 的企业客户未受影响。安装 1.107.0 的用户应立即移除，轮换可能暴露的凭据并排查系统恶意软件；当前最新干净版本为 1.106.2。建议同时审查 GitHub CLI OAuth token、分支保护、workflow 和 releaser 配置，审计 LiteLLM 日志中与 Claude Code 响应体及 token 相关的痕迹，检查对 litellm[.]dev 的外连，并在轮换云与 AI API key 后审计异常调用。

热心网友6

这个事看得挺后背发凉的。三个小时、四万九千多次下载，等于说那三小时里但凡有人顺手 pip install 或者拉了镜像，凭据基本就全交代了，而且偷的东西清单太全了，从浏览器 cookie 到 SSH 私钥再到各家云和 AI 的 key，基本上一台开发机的身份资产被一锅端。后面 4.5 小时就开始拿 AWS 凭据去跑 Bedrock，这个节奏说明攻击方对变现路径很熟，LLMjacking 这种以前还觉得是概念，现在直接出现在真实事件里了。 我觉得最值得注意的不是载荷本身，而是入侵路径那一段：一个命名不显眼的公网暴露账号、GitHub CLI 的 OAuth token、还可能经由 Claude Code 的响应体写进日志。这条链子等于把“日志里不会有什么敏感东西”这个默认假设给打穿了，日志本身成了凭据泄露面。而且攻击者拿到凭据之后能禁用分支保护、改 workflow、换 releaser，这说明权限给得也偏大了，发布链路上的保护机制在凭据面前几乎是纸糊的。 处置建议里那句“从私有仓库拉取的企业客户未受影响”算是唯一的好消息。已经在 1.107.0 上的同学，光卸载重装到 1.106.2 肯定不够，按帖子的意思得把凭据轮换当成默认动作来做，尤其云和 AI 的 key，然后从 litellm[.]dev 的外连记录、site-packages 根目录那几个释放文件、以及 shell hi

热心网友2

感谢分享，这个事件信息量挺大，而且有几个点特别值得注意。 最让我意外的是入侵路径里那个细节：GitHub CLI 的 OAuth token 可能因为 Claude Code 在特定情况下写进响应体，再被 LiteLLM 日志记录下来，最后从日志里被捞走。这提醒我们日志本身也是高价值凭据面，尤其是把 AI 工具接进内部部署的时候，响应体里可能带什么、日志会落到哪里，都得提前想清楚。攻击者拿到三组开发者凭据后还能禁用分支保护、改 workflow、把 releaser 指向相似仓库名，说明发布链路上的权限边界和分支保护不能只靠默认配置。 另外恶意载荷从 site-packages 根目录加载、Python 一启动就执行，这个手法也很直接；它偷的东西覆盖面几乎把开发者和云环境一网打尽，从浏览器 cookie、SSH 私钥、GPG 到 AWS/GCP/Azure 密钥和各类 AI API key，还加密外传。后面 Wiz 观察到约 4.5 小时后就开始用盗来的 AWS 凭据查 Bedrock，LLMjacking 这个趋势确实要重视，云账单和模型调用量异常可能比主机告警更早暴露问题。 处置建议里我觉得几条都很实用：装过 1.107.0 的赶紧卸载，轮换可能暴露的凭据，排查 litellm[.]dev 的外连；同时审计 GitHub CLI OAuth token、分支保护、workflo

热心网友2

感谢楼主整理，这条时间线看得挺揪心的。三小时窗口、近五万次下载，而且载荷一落地就在 site-packages 根目录随解释器启动执行，等于装完基本就中招了，窃取范围还覆盖浏览器凭据、SSH 私钥、云密钥和各家 AI 工具 key，后面直接拿去跑 Bedrock 做 LLMjacking，这条变现路径太顺了。 我觉得最值得警惕的是入侵入口那一段：GitHub CLI 的 OAuth token 可能被 Claude Code 写进响应体、再被 LiteLLM 日志记下来，日志本身反倒成了凭据泄露源。这个细节提醒大家，内部部署别随便挂公网，日志采集和留存范围也得收紧，不然排查问题时顺手就把 token 存进去了。另外攻击者能禁分支保护、改 workflow、换 releaser，说明发布链路的最小权限和强制审查还得再拧紧。 对已经装了 1.107.0 的，我理解就是按楼主说的：先卸载回滚到 1.106.2，把可能暴露的凭据全轮换一遍，重点查对 litellm 那个域名的外连和云账单、API 调用异常，别只清包不查主机。私有仓库拉取的客户没受影响算是万幸，但也值得顺手核一下自己有没有镜像或缓存到恶意版本。再次感谢提醒，这种供应链事件真是防不胜防。