一把没吊销的主密钥，让LiteLLM发布流程被劫持

LiteLLM在周五披露，一把在2026年5月底被误提交到公开GitHub仓库的Agent Platform主密钥，最终让攻击者向这个流行的Python包推送了恶意版本。

LiteLLM的Oliver Jensen与Mateo Wang表示，2026年5月27日，一个配置文件被提交到公开的LiteLLM-Labs/lite-harness仓库，其中无意间包含了某次LiteLLM Agent Platform部署的主密钥。该平台是他们用于编排智能体的开源工具。

按两人的说法，错误很快被发现，提交被强制推送覆盖，暴露的密钥也被标记为需要吊销。但主密钥的吊销并未执行。

从一把密钥到组织级权限

LiteLLM称，身份不明的攻击者（操作IP为69.48.229[.]143）在2026年10月10日使用了这把未吊销的密钥，进入Agent Platform，并提取了服务配置中的一个GitHub CLI OAuth令牌。该令牌原本用于让自托管的云端智能体向GitHub仓库提交拉取请求。

问题在于，这个令牌没有做权限收窄，且关联的是其GitHub组织所有者账号。拿到它，等于拿到该组织下所有仓库的所有者级访问权限，还能继续窃取其他凭据。

攻击者随后的动作按时间排列：

• 10月10日22:11至22:12（UTC）：向内部仓库的一次性分支提交内容，触发用于获取GitHub CLI OAuth令牌的工作流，目标指向两名具备维护者权限的工程师，令牌经攻击者控制的webhook[.]site端点外传。两次运行在数分钟后被删除。
• 10月21日10:08至11:08（UTC）：绕过分支保护，把发布流水线的源改为仿冒仓库“Berri-AI/litellm”，而非“BerriAI/litellm”。
• 10月21日11:39至11:40（UTC）：LiteLLM 1.107.0版本被发布到PyPI。
• 10月21日11:46（UTC）：Docker Hub与GHCR镜像发布。
• 10月21日11:53至11:54（UTC）：生产与预发布运行记录被删除。
• 10月21日12:06（UTC）：Upwind研究员Lidor Machluf报告了这起供应链攻击。
• 10月21日13:23（UTC）：PyPI隔离LiteLLM 1.107.0版本。
• 10月21日14:20（UTC）：Docker Hub上的v1.107.0、latest、main-latest、main-stable标签被移除，或重新指向经核验的干净镜像。

发布审批为何被绕过

LiteLLM解释，正常流程下，构建和发布一个版本需要由授权工程师发起，并由一个锁定在办公室物理设备上的特殊账号批准。本周这一限制被放宽，以配合更频繁发布和缺陷回补的临时需求，允许任意两名工程师触发并批准发布。

攻击者正是用其中一个令牌触发发布（此前已把部署源改指自己的恶意仓库），再用另一个令牌完成批准。维护者还指出，攻击者既然已持有组织所有者的令牌，完全可以自行放宽甚至移除这一限制；据其判断，未这样做是为了规避检测。

LiteLLM表示，这些工作流的设计目的是识别并外传更多密钥与令牌，重点针对上游推理API令牌。事件发生后，公司称正在吊销与每个内部系统和供应商平台相关的全部令牌。

工作流细节与初始判断被推翻

Socket在独立调查中称，恢复了两个恶意提交，各自在“.github/workflows/cache.yml”添加了一个工作流。第一个提交时间为2026年10月10日22:11:45（UTC），第二个在10月12日。

Socket安全研究员Karlo Zanki表示，两个提交都没有推送到仍然存在的分支，而是推送到名为ci-tmp-的短命分支，创建、使用、删除都在几分钟内完成，因此仓库的常规历史里几乎不留痕迹。两次提交都以一个合法提交作为分支基点，让推送看起来无害：从近期合法提交创建一次性分支，推送添加cache.yml的提交，提交信息同为“ci: bump cache config”，工作流配置为每次提交或标签推送时触发，随后删除分支。

两个工作流都能收割GitHub令牌，以及组织Linear工作区、LiteLLM部署和Together AI的API密钥，还包括一个GitHub App的标识与签名密钥。10月12日那次运行把收集范围扩大到Anthropic、OpenAI、AWS Bedrock、Tavily的API密钥，以及GitGuardian密钥扫描租户的凭据，还抓取Playwright存储状态、PostgreSQL数据库信息（连接串、账号名、密码）、Redis端点地址、端口与认证密码。数据被外传到两个不同的webhook[.]site端点。

Zanki指出，GitHub令牌和GitHub App私钥是托管仓库平台的凭据，而非第三方服务的凭据；GITGUARDIAN_API_KEY是密钥扫描平台本身的凭据，拿到它就能看到、甚至控制本应暴露此类活动的告警；E2E_LINEAR_STORAGE_STATE_B64是Playwright端到端测试使用的序列化浏览器会话状态，有效的存储状态可以免密、免多因素认证访问关联的Linear账号。

这些发现推翻了LiteLLM最初的假设——GitHub CLI OAuth令牌是从某次内部部署日志中被窃取的。Jensen承认，调查是一个不断获知新信息的过程，部分假设和判断后来被证明不准确或不完整。

恶意版本做了什么

多份报告显示，LiteLLM 1.107.0捆绑的文件被设计为在Python启动时自动执行，即便应用并未导入LiteLLM。恶意代码有两条执行路径：一个凭据收割模块，目标覆盖开发者工具、AI应用、云环境和浏览器中的认证材料；一个面向Unix的后门，以后台进程启动，每小时拉取并执行攻击者下发的任意代码。

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

微软安全研究团队表示，这些机制把潜在暴露面扩展到活跃的LiteLLM部署之外：只要在受影响环境中启动Python，就可能激活恶意代码，哪怕从未导入LiteLLM。由于启动文件位于LiteLLM应用目录之外，仅删除应用文件可能把恶意启动组件留在原处。