|
AI行业复盘 ｜ 国企AI治理专题 AI网关被投毒！43万流水线翻车复盘 |
AI泄密 不是别人的故事。大模型统一网关失守，企业AI治理整条信任链跟着塌——开源 AI 网关 LiteLLM 被供应链投毒，一枚没吊销的 token 撬开 2500 多家企业，约 43 万条流水线被拖下水。对国企 IT 负责人来说，这恰恰是最该后背发凉的一幕：攻击者根本没碰你的服务器，只碰了你信任的那段管道。
LiteLLM 是部署最广的开源大模型代理网关，月下载量约 9700 万次，受害对象集中在 RAG 系统、AI Agent 平台、大模型网关与企业 AI 应用。它是一段没人审计的依赖，却扛着你最值钱的云密钥与模型 API Key 跑在 CI 流水线上。下面把整条攻击链按时间线拆开，每一步都标出"这一环本来可以拦住"。
一、40分钟：一个AI网关如何把43万条流水线拖下水
先给一个数字定调：两个投毒版本在 PyPI 公开存在约 40 分钟，就被维护者发现并删除。但 CI 流水线以机器速度安装依赖，40 分钟足够一批流水线把恶意包拉进自己的 runner。等到 2026-08-11 CloudSEK 首次完整披露受害面时，数字已经大到让人头皮发麻：2500 多家企业、约 434000 条 CI/CD 流水线可能暴露。
Hudson Rock 独立分析了 153GB 泄露归档，确认 2488 个企业域名、118829 份 CI runner 转储。受影响公开清单里站着一长串名字——英伟达、三星电子、思科、西门子、标普全球、ServiceNow、德勤、沃达丰、X Corp、Zscaler、FedEx、大众汽车、罗氏制药、空客美国航天与防务、约翰迪尔。这不是"小厂翻车"，而是全球供应链同时中招。
为什么一个开源网关能牵动 43 万条流水线？因为它处在"所有 AI 调用都要经过的地方"。RAG 系统、AI Agent 平台、企业 AI 应用，几乎都把它当默认水管用——所以水管被投毒，下游全部跟着喝水。大模型统一网关的杠杆，平时是效率，出事时是杀伤面。
二、攻击链拆解：一枚没吊销的token，是怎么变成2500家企业的凭据泄露
把时间线摊开，这是一条教科书级的供应链投毒链，共九个环节，每一环都有机会被拦住。下面按顺序讲清，每一环都点出"本来可以拦住"的那道闸。
1. 起点：一枚没被彻底吊销的 token。开源漏洞扫描器 Trivy 此前发生过一次独立安全事件，处置时轮换了被泄露的认证 token，但完全没吊销。残留访问权限就这么留了下来——这一环本来可以拦住：轮换后立刻吊销旧 token，残留权限归零。
2. 劫持可信工具：2026-03-19，攻击组织 Team PCP 用这份残留权限，向 Trivy 的 GitHub 发布 tag 强推恶意提交。trivy-action 仓库被劫持 75 个 tag，把一个受信任的安全工具变成凭据窃取器。关键是没有发布任何新版本，因此不会引起审视——这一环本来可以拦住：发布 tag 强制双人复核与签名校验，异常强推立刻告警。
3. 顺流进 CI：五天后 2026-03-24，LiteLLM 自己的构建流程做了绝大多数 CI 流水线都会做的事——不固定版本、直接从源拉取 Trivy。被投毒的扫描器在 LiteLLM 的 GitHub Actions 环境里运行，读取 runner 内存，窃走 LiteLLM 的 PyPI 发布 token——这一环本来可以拦住：依赖锁版本、固定哈希，不从源动态拉取。
4. 投毒分发包：攻击者用该 token 向 PyPI 推送两个投毒版本 1.82.7 与 1.82.8。1.82.7 把窃取逻辑嵌在业务模块里，需要业务代码 import litellm 才触发；1.82.8 加了 .pth 启动钩子——只要 Python 解释器启动，载荷就自动运行，触发条件被压到最低。GitHub 源码仓库没有对应提交记录，恶意代码只存在于 PyPI 分发包内——这一环本来可以拦住：源码与分发包一致性校验，PyPI 发布走受控通道。
5. 40 分钟的窗口：两个恶意版本在 PyPI 公开存在约 40 分钟后被维护者发现删除。但对流水线来说，机器速度安装依赖，40 分钟已经够用——这一环本来可以拦住：依赖缓存与私有镜像源，阻断对公网 PyPI 的实时拉取。
6. 三阶段载荷：首次执行收集全部环境变量与本地配置文件（.kube/config、.aws/credentials、能触达的 .env）→ 尝试在 Kubernetes 集群横向移动 → 安装 systemd 持久化后门，即使恶意包被删除也保留访问。部分外传失败的情况下，恶意程序会在受害者自己的 GitHub 账号里创建公开仓库、把窃取数据当作 release 资产上传——把受害者账号变成泄露通道。
7. 受害面曝光：2026-08-11 CloudSEK 首次完整披露。2500 多家企业、约 434000 条 CI/CD 流水线可能暴露；Hudson Rock 独立分析 153GB 泄露归档，确认 2488 个企业域名、118829 份 CI runner 转储；公开清单包含前述一众头部企业。
8. 泄露了什么：AWS/Azure/GCP 云密钥、OpenAI/Anthropic/Google/Cohere 等 AI 服务商 API Key、GitHub token 与 SSH 密钥、K8s 集群密钥、数据库凭据、环境变量、软件包发布凭据。一句话——你最该锁的那串钥匙，全在漏的清单里。
9. 长尾风险：FBI 于 2026-07-02 发布 FLASH 通告（FLASH-20260702-01），警告被窃凭据在入侵后很久仍可被利用。这一点，留到下一节展开——它才是真正让国企 IT 负责人后背发凉的部分。
三、为什么这次特别难防：管道型依赖、看不见的分发包与.pth启动钩子
这起事件最反直觉的地方，是它几乎不触发任何"看起来异常"的信号。三个特征叠加，让它成为防守方的噩梦，也解释了为什么传统审计常常扑空。
1. 管道型依赖，无人审计。LiteLLM 是"管道"不是"产品"，没人会把它写进 PPT，因此正是那种没人审计的依赖。国企与大型集团的 AI 中台大量采用同类开源组件自建，默认信任上游，从不看上游的上游发生了什么——信任链条一长，任何一环破，全盘跟着破。
2. 看不见的分发包。恶意代码只存在于 PyPI 分发包内，GitHub 源码仓库没有对应提交记录。看源码看不出异常，这是本次攻击极具欺骗性的地方——你盯着公开仓库审代码，攻击者在你拉包的那一秒才动手，审计视线与攻击时刻完美错开。
3. .pth 启动钩子把触发条件压到最低。传统投毒要等业务代码 import 才触发，1.82.8 直接挂到 Python 解释器启动钩子上，解释器一启动载荷就跑。意味着即使你"没用到那个功能"，只要环境里装过，就中招。再加上 systemd 持久化后门与"把受害者账号变泄露通道"的外传兜底，清理难度远超一次性入侵，普通卸载根本清不干净。
对国企 IT 负责人而言，这三点的合起来指向一句话：你以为的"安全依赖"，可能只是还没被投毒的依赖。企业AI治理的第一课，不是买更贵的扫描器，而是先搞清楚"我到底依赖了什么、谁在替我盯着上游"。
四、卸载不等于安全：被窃API Key会替你烧掉大模型账单
很多人以为"删掉恶意包就完事了"。FBI 的 FLASH 通告（FLASH-20260702-01）给出的判断是：被窃凭据在入侵后很久仍可被利用。次生伤害远大于单次入侵——这才是这起事件最该写进国企安全手册的一句。
卸载恶意包不等于安全，因为被偷走的 API Key、云 AccessKey、K8s Secret、Git token 依旧有效。攻击者可以用它调用大模型接口消耗企业配额、访问云资源、横向渗透业务集群。换句话说，被窃的 API Key 会替你烧掉大模型账单——Token成本暴涨不全是市场价涨，还有人拿你的钥匙 24 小时替你下单。
这也是为什么这次事件里最该警惕的，不是那 40 分钟，而是 40 分钟之后的几个月：只要有一把有效 Key 还漂在外面，你的模型额度、云额度就还在持续失血。排查清单不能止于"装没装恶意包"，而要落到"哪些 Key 可能被看见、现在是否还有效、要不要立刻轮换"——这个动作，必须在事件爆发的当天做，而不是等月底账单异常才反推。
这里还有一条重要边界必须写清：434000 不等于全部完成密钥窃取。部分流水线存在网络隔离、出站阻断、运行环境无高价值密钥，不会产生泄露；但只要拉取过恶意包，就必须执行处置，不能抱有侥幸。"没泄露"和"不用处置"是两件事，前者是概率，后者是纪律。
五、国企AI中台该补的四课：依赖固定、凭据集中、调用收口、全量审计
回到国企场景。LiteLLM 月下载量约 9700 万次，受害对象集中在 RAG 系统、AI Agent 平台、大模型网关、企业 AI 应用。国企与大型集团的 AI 中台大量采用同类开源组件自建，问题高度一致，可归纳为四课——这也是企业AI治理最容易欠账的四个角落。
1. 依赖固定：别让流水线从源动态拉取。不固定版本、供应链信任链条过长是第一道裂缝。把依赖锁版本、固定哈希、走私有镜像源，CI 不再实时访问公网源，投毒窗口直接关掉。这一课解决的是"上游被投毒，下游跟着中招"的传导。
2. 凭据集中：别让密钥散落在流水线环境变量里。当前普遍由各团队各自持有 Key，出事时连"要轮换哪些 Key"都列不出来。把凭据从"各团队各自持有"变成"网关侧集中托管、按需签发、可一键轮换"，出事时一键收口，而不是翻遍十几个仓库找 token。这一课解决的是"出事后不知道要换什么"的盲区。
3. 调用收口：别让模型调用没有统一出口。缺少统一出口，就无法回答"这段时间谁在用我的额度"。所有对模型的调用经由统一网关，私接的 API、未登记的智能体无处藏身，额度才第一次变成可观测的资产。这一课解决的是"用没用、被谁用"说不清的失控。
4. 全量审计：别等账单异常才反推。缺少运行时调用可见性，只能事后从账单异常反推。全量审计让"谁在什么时候用了哪个模型、处理了什么类型的内容"可查，异常调用（陌生来源、非工作时段、异常峰值）可被发现。这一课解决的是"出事了才发现自己一直被用着"的滞后。
这四课的落地，正是 51Tokens 咨询落地服务最常见的切入方式——从收口一个网关、集中一批凭据、拉起一份审计开始，把国企 AI 治理的红线钉进系统；再配合 51Tokens 培训课程，让研发、安全、业务部门真正理解"开源依赖不是免审金牌，管道型组件也要有人盯"。
六、写在最后：AI省钱、AI合规、AI考核是同一条链路
把上面的事收敛成一条能落地的链路：统一网关把凭据托管从"各团队各自持有"变成"网关侧集中托管、按需签发、可一键轮换"；全量审计让"谁在什么时候用了哪个模型、处理了什么类型的内容"可查，异常调用可被发现；敏感内容识别在请求进入模型之前工作，规则在 51Tokens 侧配置管理、编译成规则包下发、由 51API 网关在运行时执行——管理与执行分离，五种处置动作 PASS 放行 / WARN 提醒 / MASK 脱敏放行 / BLOCK 拦截 / APPROVAL 转审批。
同一条链路上，请求侧自研保真压缩 30%-70%，语义不丢、效果不打折，模型返回内容原样透传——把成本压下来，把风险拦下来，不替模型改一个字。
下面这三件事，本质是同一件事的三个切面：
① AI 合规：敏感内容识别与全量调用审计，把凭据泄露与数据外传风险从盲区拉回可观测区；
② AI 考核：调用数据可查可统计，把 AI 贡献从"凭印象"变成"有数据"；
③ AI 省钱：请求侧自研保真压缩与分级预算，把 Token 账单从变量项拉回可控项。
它们共用同一条基础设施：一条能看见每一次模型调用的链路。
需说明：51Tokens 的敏感内容识别是提醒与拦截双模式，把风险判断从个人记忆搬到系统规则，不替代任何保密审查流程，也不承诺 100% 合规；它解决"看得见、拦得住"，不替代 DLP / SIEM 等专业安全系统。
最后留三个问题给屏幕前的你：
1. 你们 CI 流水线的依赖，有固定版本与哈希吗，还是还在实时从源拉取？
2. 一旦出事，你能在一小时内列出"要轮换哪些 Key"吗，还是得翻遍十几个仓库？
3. 你们的大模型调用，走的是统一网关还是各团队私接的 API？
欢迎在评论区聊聊：你们公司怎么管开源 AI 组件的依赖与凭据？如果还在"装完就用"，把这篇转给 IT 负责人和安全团队，可能比转给任何人都更及时。
—— 51Tokens，让每一次模型调用都看得见、说得清、查得到
图：51AIPro 全流程 AI 治理一体化解决方案 · 服务架构
