导语：2026年3月，一场堪称史上规模最大的AI基础设施供应链攻击悄然登场。威胁组织TeamPCP先入侵热门漏洞扫描工具Trivy的GitHub Actions管道，再利用LiteLLM对其的信任链注入恶意代码神不知鬼不觉地渗透进全球数千家企业的CI/CD环境——直到153GB的原始泄露数据库浮出水面，安全界才看清这场攻击的真正规模。
一、事件概述
LiteLLM是开源圈极为流行的AI代理网关解决方案，被广泛用于在各类LLM供应商之间路由请求，日下载量高达340万次。然而树大招风，3月下旬，TeamPCP通过一系列精妙的供应链渗透手法，将这块”AI基础设施积木”彻底变成了特洛伊木马。
根据安全公司Snyk、Trend Micro和Cycode的详细取证分析以及威胁情报厂商CloudSEK和Hudson Rock的追踪研究，这场攻击的规模令人咋舌：波及2500多家企业、涉及43.4万个CI/CD管道，而Hudson Rock最终获取到的原始泄露数据库高达153GB，内含433,909个文件。
二、攻击路径解析：从Trivy到LiteLLM的五层渗透
这场攻击的精妙之处在于它并非直接攻击LiteLLM，而是打了一条迂回曲折的供应链穿透路线。
2.1 第一层：Trivy的GitHub Actions管道被攻破
TeamPCP首先对Trivy——一款极受欢迎的 开源漏洞扫描器——的GitHub Actions CI/CD管道下手。攻击者获得了Trivy的GitHub Actions运行器环境的读取权限。
2.2 第二层：利用信任链渗透LiteLLM
由于LiteLLM的开发团队在其CI/CD管道中使用了Trivy，被污染的扫描器因此获得了对LiteLLM运行器环境的合法读取访问。攻击者借此机会悄无声息地窃取了LiteLLM的PyPI发布令牌。
2.3 第三层：PyPI仓库投递恶意包
拿到令牌后，TeamPCP在PyPI上发布了LiteLLM的恶意版本——1.82.7和1.82.8。这两个版本被推送到了全球最大的Python包仓库，等待开发者自行下载。
2.4 第四层：.pth钩子实现无感触发
payload的投递方式极为隐蔽。攻击者利用了Python的.pth启动钩子机制——只要Python解释器初始化，恶意代码就会自动执行，无论代码是否显式导入了LiteLLM库。
2.5 第五层：三阶段payload全面收割
恶意代码包含一个三阶段payload：
- 第一阶段：读取环境变量
- 第二阶段：窃取本地配置文件（.kube/config、.aws/credentials等），尝试在Kubernetes集群中横向移动
- 第三阶段：安装持久化的systemd后门（伪装成”System Telemetry Service”）
三、153GB数据泄露：哪些秘密被收割了
Hudson Rock安全研究团队独立获取并分析了泄露的原始数据库。这份153GB的RAR压缩包共包含433,909个文件，其中118,829个CI运行器转储可归因到2488个受影响的企业域名。
3.1 云基础设施密钥
AWS_SECRET_ACCESS_KEY、WORKLOADS_DEV_AWS_SECRET等各类云环境密钥以明文形式直接暴露，攻击者可凭此直接访问受害企业的云资源。
3.2 内部企业凭证
大量企业内部平台令牌被截获，包括Salesforce客户端密钥、Slack签名密钥、微软Azure环境凭证，以及各类数据库密码。
3.3 AI提供商API密钥
LiteLLM作为AI网关的本职特性导致了一个极具讽刺意味的后果——受害者自己的LLM路由基础设施的API密钥也被一并收割，攻击者由此获得了直接访问企业LLM路由权限和计费配额的能力。
四、归因难题：谁中招了
4.1 邮件不可信，基础设施标识才靠谱
归因这些泄露数据的受害者身份本身就是一大挑战。例如，某高调泄露事件的提交者邮箱属于@siriusxm.com，但研究团队通过分析CI_SERVER_FQDN=gitlab.adswizz.com和registry.adswizz.com等基础设施端点，最终确认这起事件实际上发生在AdsWizz（SiriusXM的子公司）的基础设施内。
4.2 隐形受害者：不知道自己已经沦陷
更令人担忧的是，泄露数据中有大量文件包含高度敏感的密钥，却完全没有任何组织归属标识。许多CI/CD管道的配置是通用的——泄露的变量中包含活跃的数据库密码、第三方API密钥和云凭证，却没有可识别的公司邮箱、自定义域名字符串或内部服务器名称。这意味着无数企业目前正有活跃密钥躺在这份数据库里，而他们对此一无所知。
五、波及企业清单
以下为受影响的部分知名企业：
| 组织 | 域名 |
|---|---|
| 亚马逊网络服务（AWS） | amazon.com |
| 三星电子 | samsung.com |
| 思科系统 | cisco.com |
| Salesforce | salesforce.com |
| ServiceNow | servicenow.com |
| S&P Global | spglobal.com |
| 西门子 | siemens.com |
| 约翰迪尔 | deere.com |
| 德勤 | deloitte.com |
| Epic Games | epicgames.com |
| 橙色电信（Orange） | orange.com |
| TomTom | tomtom.com |
| BT Group | bt.com |
以三星为例，Cavalier平台自动归类了17个被入侵的管道转储，暴露了数百个敏感资产，包括Bitbucket部署令牌、Elastic API密钥、内部JWT和NPM令牌。
六、处置建议
如果你的组织使用了AI代理基础设施、第三方CI/CD漏洞扫描器或下游AI包，请立即执行以下措施：
紧急凭证吊销：假设LiteLLM环境可访问的任何密钥均已泄露。立即吊销并轮换所有AWS/GCP/Azure IAM密钥、Kubernetes服务账号令牌和GitLab/GitHub个人访问令牌。
审计日志与出口过滤：审查自2026年3月24日以来的AWS CloudTrail和Kubernetes API审计日志，查找异常活动。在运行器环境中实施严格的网络出口过滤。
持久化排查：检查本地开发环境和容器中site-packages目录是否存在未授权的.pth文件，查找可疑的systemd服务（例如伪装成”System Telemetry Service”的服务）。
紧急版本核查：立即审计环境中的LiteLLM版本，确认是否使用了1.82.7或1.82.8——若中招，立即隔离并重新部署来自可信来源的干净版本。
七、结语
这事儿吧，得从两边儿看——红队这波供应链攻击的操作确实满分，先拿下Trivy再曲线渗透LiteLLM，五层穿透步步为营，完美诠释了什么叫”攻其必救不如攻其所赖”；但蓝队这边暴露的问题也同样触目惊心——CI/CD管道里躺着的密钥比生产环境的防火墙还多，谁中招的不知道，甚至不知道自己已经中招的更是大有人在。
这波操作给所有AI基础设施玩家的教训很明确：你的安全边界，取决于你供应链上最脆弱的那一环。
图片版权 华盟网
暂无评论内容