LiteLLM主密钥泄露，攻击者窃取GitHub令牌劫持发布流水线

LiteLLM于周五披露，2026年5月底，一枚Agent Platform主密钥被意外发布到公开GitHub仓库，最终导致攻击者推送了这款热门Python包的恶意版本。

LiteLLM的Oliver Jensen与Mateo Wang表示：“2026年5月27日，公开仓库LiteLLM-Labs/lite-harness收到一份配置文件提交，文件意外包含LiteLLM Agent Platform部署环境的主密钥，该平台是我们用于编排Agent的开源工具。我们很快发现了这一错误，强制推送覆盖了该提交，也确认需要吊销已泄露的密钥，但最终并未吊销这枚主密钥。”

LiteLLM表示，来自IP地址69.48.229[.]143的未知攻击者于2026年10月10日利用这枚未被吊销的密钥访问Agent Platform，提取了服务配置的GitHub CLI OAuth令牌——该令牌原本用于支持自托管云Agent向GitHub仓库提交拉取请求。

这家开源大语言模型（LLM）网关的开发人员表示，该令牌未做权限范围限制，且绑定到其GitHub组织所有者账户。

攻击者获取该令牌后，获得了组织内所有仓库的所有者级权限，进而窃取了更多凭证。攻击者后续的操作时间线如下：

• 2026年10月10日 UTC时间晚上10:11至10:12：攻击者向内部仓库（BerriAI/litellm、BerriAI/litellm-auto）的临时分支提交代码，运行工作流，通过攻击者控制的webhook[.]site端点窃取两名拥有维护者权限工程师的GitHub CLI OAuth令牌。相关运行记录在数分钟后被删除。
• 2026年10月21日 UTC时间上午10:08至11:08：攻击者绕过分支保护规则，篡改发布流水线，将代码源从官方仓库“BerriAI/litellm”替换为仿冒仓库“Berri-AI/litellm”。
• 2026年10月21日 UTC时间上午11:39至11:40：LiteLLM 1.107.0版本被发布到PyPI。
• 2026年10月21日 UTC时间上午11:46：Docker Hub与GHCR镜像发布。
• 2026年10月21日 UTC时间上午11:53至11:54：生产环境与预发布环境的运行记录被删除。
• 2026年10月21日 UTC时间中午12:06：Upwind研究员Lidor Machluf上报这起供应链攻击。
• 2026年10月21日 UTC时间下午1:23：PyPI对LiteLLM 1.107.0版本采取隔离措施。
• 2025年10月21日 UTC时间下午2:20：Docker Hub移除v1.107.0、latest、main-latest、main-stable标签，或将其重新指向已验证的干净镜像。

LiteLLM表示：“正常流程下，版本构建与发布必须由授权工程师触发，再由绑定办公室物理设备的特殊账户审批。”

2026年5月泄露的主密钥

“本周早些时候，我们放宽了这一限制，以便临时提升发布频率、回溯漏洞修复补丁，允许任意两名工程师触发并审批发布流程。攻击者因此得以用一枚窃取的令牌触发发布（此前已将部署目标重定向至其恶意仓库），再用另一枚令牌完成审批。”

此外，项目维护人员指出，攻击者已经持有组织所有者的令牌，完全可以自行放宽甚至彻底移除这一限制，推测其未这么做是为了规避检测。

LiteLLM还表示，这些恶意工作流专门用于识别并窃取更多密钥与令牌，重点目标是上游推理API令牌。针对此次事件，该公司正着手吊销所有内部系统与供应商平台关联的每一枚令牌。

Part01

恶意工作流细节披露

安全厂商Socket发布了针对恶意工作流的独立调查报告，称其发现两处恶意提交，每笔都在.github/workflows/路径下新增cache.yml文件。第一笔提交发生在2026年10月10日UTC时间晚上10:11:45，第二笔在10月12日。

Socket安全研究员Karlo Zanki在向《黑客新闻》提供的报告中表示：“两笔提交都没有推送到目前仍存在的分支上，而是都推送到名为ci-tmp-的短生命周期分支。这类分支从创建、使用到删除全程仅数分钟，因此仓库常规历史中几乎不会留下相关活动痕迹。”

根据这家应用安全厂商对仓库活动日志的分析，两笔提交都以一笔合法提交作为分支基础，让推送操作看起来毫无异常，具体流程如下：

• 从仓库近期的一笔合法提交切出名为“ci-tmp-”的临时分支（具体为ci-tmp-a351cc、ci-tmp-4d8517）。
• 推送新增.github/workflows/cache.yml文件的提交，两次提交的说明均为“ci: bump cache config”。
• 工作流配置为每次提交或标签推送时自动运行（即触发规则为[on: [push]]），因此提交推送后工作流立即执行。
• 删除分支。

LiteLLM指出，这两个工作流都具备窃取GitHub令牌、组织Linear工作区密钥、LiteLLM部署密钥、Together AI API密钥，以及某GitHub App标识符与签名密钥的能力。

10月12日运行的工作流扩大了窃取范围，覆盖更多敏感信息，包括Anthropic、OpenAI、AWS Bedrock、Tavily的API密钥，以及GitGuardian密钥扫描租户的API密钥。该工作流还会窃取Playwright存储状态、PostgreSQL数据库信息（连接字符串、账户名、密码）、Redis端点地址、端口与认证密码。

两次工作流窃取的数据会被发送到两个不同的webhook[.]site端点：

• webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37
• webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1

Zanki表示：“GitHub令牌与GitHub App私钥是代码托管平台的凭证，而非第三方服务凭证。GITGUARDIAN_API_KEY是密钥扫描平台本身的凭证，攻击者获取后可以查看甚至操控本应监测到此类恶意活动的告警。”

“E2E_LINEAR_STORAGE_STATE_B64是Playwright用于端到端测试的序列化浏览器会话状态，有效的存储状态可以让攻击者无需密码、无需通过多因素认证，直接登录关联的Linear账户。”

这些发现推翻了LiteLLM最初的假设——该公司此前认为GitHub CLI OAuth令牌是从内部LiteLLM部署的日志中被盗的。Jensen承认：“调查是一个不断获取新信息的过程，这意味着我们最初的部分假设和判断后来被证实不准确或不完整。”

Part02

恶意包暗藏窃密后门

多份报告显示，LiteLLM 1.107.0版本捆绑的文件被设计为在Python启动时自动执行，即便应用并未导入LiteLLM也会触发。

该恶意程序包含两条执行路径：一是凭证窃取模块，针对开发者工具、AI应用、云环境、网页浏览器中的认证信息；二是面向Unix系统的后门，以后台进程运行，每小时拉取并执行攻击者下发的任意代码。

遭篡改的LiteLLM 1.107.0执行流程

窃密模块还会收集系统信息、SSH文件、Git与GitLab凭证及令牌、环境变量，以及npm、PyPI、pip、Yarn、Maven、Gradle、Composer、RubyGems、Cargo相关的令牌。窃取的数据会被压缩后，通过HTTP POST请求发送到域名litellm[.]dev/healthcheck，该域名注册于2026年10月13日。

微软安全研究团队表示：“这些机制让潜在受影响范围不再局限于正在运行的LiteLLM部署：只要在受影响环境中启动Python，就可能激活恶意代码，哪怕从未导入过LiteLLM本身。”

“由于恶意启动文件位于LiteLLM应用目录之外，仅删除应用文件可能会残留恶意启动组件。”

推荐阅读

电报讨论