2026年3月的某一天，开源AI开发工具LiteLLM的两个版本——1.82.7和1.82.8——被植入窃密代码。代码运行后扫描本地内存、打包凭证、发往攻击者控制的服务器，整个窃取窗口只有40分钟。
五个月后，安全公司CloudSEK和Hudson Rock先后披露战果：这40分钟牵出逾2500家组织的高置信度凭证暴露线索，约43.4万条CI/CD流水线受影响，Hudson Rock拿到并分析的原始数据文件规模达195TB。这不是某家公司系统被单独攻破，而是一条开源依赖出了问题，代价摊到了几千家机构头上。
LiteLLM遭投毒：40分钟窃取窗口，牵出四十万条流水线
LiteLLM是开发者统一调用不同AI模型接口的开源代理层。很多团队把它嵌进CI/CD流水线，方便AI功能快速上线。
攻击者篡改的1.82.7和1.82.8版本一旦被拉取运行，会窃取环境里的云密钥、GitHub/GitLab令牌、SSH密钥、Kubernetes凭证，以及AI服务商自己的API密钥。窗口只有40分钟，但足够覆盖大量自动拉取最新版本的流水线。
| 时间节点 | 事件 |
|---|---|
| 更早 | 漏洞扫描工具Trivy遭投毒，成为入侵跳板 |
| 随后 | KICS、Telnyx Python SDK相继感染 |
| 2026年3月 | LiteLLM 1.82.7、1.82.8被植入窃密代码，40分钟窃取窗口 |
| 2026年8月前后 | CloudSEK、Hudson Rock先后披露波及规模 |
自称作案的黑客团伙TeamPCP公开认领，独立研究者Kevin Beaumont核实后确认数据属实。据Beaumont描述，TeamPCP核心成员多为青少年——这条链路的讽刺之处在于，入侵的技术门槛并不高，暴露的其实是企业自己在DevSecOps上的疏漏。
真正的风险在权限链：AI代理为何放大攻击半径
把这件事简单归因为"AI遭黑"会漏掉重点。LiteLLM本身不比其他开源依赖更脆弱，问题在于它站在权限链的关键位置——一头连着模型调用，一头连着流水线里几乎所有能拿到的密钥。
企业越急着把AI代理接进开发环境，这个中间层能触达的敏感信息就越多。上游一旦被投毒，波及范围会比普通依赖库更大。这和历史上event-stream、ua-parser-js等npm投毒事件性质相同，区别只是这次中间层换成了AI工具，权限半径更大。
CloudSEK公布的高置信度名单里，出现了Nvidia、AWS、Samsung、Salesforce、Cisco、Siemens、Volkswagen、Deloitte等名字。但这只是凭证暴露的高置信线索，不等于这些公司的核心系统已经失陷。
归属判断也会出偏差。名单里一个来自@siriusxm.com域名的邮箱地址，最终查明泄露的是其子公司AdsWizz的基础设施，跟卫星广播主业务没关系。
43.4万条流水线，不能直接等同于43.4万家受害企业——一家公司往往同时运行多条流水线。195TB是Hudson Rock拿到并分析的原始数据文件规模，不等于全部是可用的有效凭证。很多CI/CD环境变量是泛化配置，没有可识别的公司域名或邮箱，这意味着还有一批组织完全不知道自己已经暴露。
谁该现在动手：开发者、安全负责人分别要做什么
Trivy事件留下过一个教训。开发者当时把自动化令牌做了轮换，却没有彻底撤销，留出约20天空窗，攻击者借着这个空窗继续向下游第三方仓库强推恶意代码。
一条依赖出问题，代价却要几千家机构埋单。
CloudSEK和Hudson Rock都把这个案例当警示，因为LiteLLM事件的补救方式很容易重蹈覆辙。
| 对象 | 现在该做什么 |
|---|---|
| 用过LiteLLM 1.82.7/1.82.8、接入AI代理或依赖下游AI包的开发与DevSecOps团队 | 立即撤销并重新签发所有可能暴露的凭证——云密钥、K8s服务账号令牌、GitHub/GitLab个人访问令牌；只升级版本或改一次密码不够，要按Trivy事件的教训彻底撤销而非仅轮换 |
| 负责云凭证、CI/CD流水线和开源依赖治理的企业安全负责人 | 排查是否引入过受污染版本，审计访问日志和出站流量，确认没有留下类似Trivy那样的长尾窗口；同时清点CI/CD变量里是否带可识别域名或邮箱，避免成为名单之外"不知道自己已暴露"的一员 |
没有用过LiteLLM相关版本、也没有接入AI代理的团队，这次不需要跟风操作。但可以顺手核对一下自己的CI/CD变量里，是否也混有过期或过度授权的密钥。
【锐评】40分钟的窃取窗口不算什么，真正暴露的是几千家机构把AI工具塞进高权限管道时，从没问过一句"这层中间件的权限该有多大"。