AI供应链危机：Mercor数据泄露与LiteLLM投毒事件

3月底，AI招聘领域的独角兽企业Mercor遭遇了严重的数据泄露事件，泄露的数据量高达4TB。对于一家估值100亿美元、客户涵盖OpenAI、Anthropic和Google DeepMind的公司而言，这一事件无疑极具冲击力。

然而，这起事件远非简单的“安全措施不到位”所能概括。

从公开的信息来看，这是一次典型的AI时代供应链攻击案例：攻击者并未直接突破Mercor的核心防线，而是通过“安全工具GitHub Actions被攻陷→PyPI包被篡改→AI网关凭证被盗取→下游企业大规模受损”的路径层层渗透，最终瞄准了最具价值的数据资产。

若仅将此事件视为一次普通的数据泄露，无疑是低估了其潜在的警示意义。

根据已披露的信息，攻击最早始于2026年2月底至3月期间。攻击组织TeamPCP先后攻陷了两个开源安全扫描器项目的GitHub Actions：Trivy和KICS。

这两个工具并不陌生。Trivy广泛应用于云原生和容器安全领域，而KICS则常用于IaC配置的安全检查。它们原本是帮助企业保护供应链安全的工具。

然而，攻击者首先拿下了这些上游的安全基础设施。

随后，在3月24日，TeamPCP利用窃取到的凭证，向PyPI上传了被篡改的LiteLLM 1.82.7和1.82.8版本。LiteLLM是一个大模型API统一网关，负责将OpenAI、Anthropic、Google等不同厂商的接口封装为统一调用方式，月下载量超过9500万次。

这一步至关重要。

在当今的大模型应用架构中，LiteLLM这类网关不仅仅是“转发层”，更是整个AI系统的流量中枢和凭证集中器。它通常保存多家模型提供商的API Key、路由配置、限流规则、日志信息以及调用链路，甚至与监控、缓存、计费系统紧密关联。

谁控制了网关，谁就获得了进入整套AI基础设施的“通行证”。

此次LiteLLM投毒事件最值得技术团队警惕的一点在于，恶意代码利用了.pth文件机制。

许多开发者对这一细节并不敏感，但其威力极大：.pth文件可以在Python解释器启动时自动执行代码。这意味着，即使受影响环境中没有显式导入litellm模块，只要Python进程启动，恶意逻辑也可能已被触发。

这意味着什么？

这不是传统意义上的“使用危险函数导致漏洞”的问题，而是环境级、解释器级的启动时执行行为。这种攻击方式绕过了许多人的直觉防线，也显著增加了排查难度。很多团队在进行依赖审计时，关注的是业务调用链，却未必留意Python启动路径和site-packages中的那些不起眼的启动钩子。

对攻击者而言，这种方式极为划算：隐蔽性强、稳定性高、触发门槛低，且适合大规模收集凭证。

过去几年，安全行业一直在提醒“不要将Secrets散落在代码和脚本中”。但在AI应用真正运行后，问题并未消失，只是转移到了更集中的地方。

统一网关就是这样的集中点。

为了同时接入多家模型服务，企业往往会将OpenAI、Anthropic、Google DeepMind乃至自建模型平台的密钥、代理配置、回退策略全部集中到网关层。这样做在工程上非常合理：便于切换厂商、便于限流、便于统一日志管理，也便于成本控制。

但从攻击者的视角看，这就形成了一个极高价值的单点攻击目标。

过去，攻击者若想获取10家服务商的凭证，可能需要分别攻击10套系统；而现在，他只需拿下一个网关实例，就能一次性获取整组凭证。更现实的是，许多AI团队的安全成熟度仍停留在传统Web应用阶段，对“模型调用层实际上已成为新的身份边界”这一认知不足。

因此，这次攻击的本质并不仅仅是PyPI被投毒，而是攻击者精准地瞄准了AI基础设施中最易被低估但价值最高的节点。

Mercor的数据规模解释了为何攻击者会盯上它。

根据披露信息，此次泄露共涉及约4TB数据，其中包括939GB平台源代码、211GB用户数据库，以及3TB对象存储桶数据。后者尤其敏感：包含数千小时高清面试视频、护照和驾照扫描件、面部生物识别信息。受影响的承包商个人数据超过3万人。

如果说源代码和数据库泄露意味着业务系统暴露，那么面试视频、身份证件、面部数据泄露，则意味着另一层更难逆转的后果。

代码泄露了，还能重构；Key泄露了，还能轮换；但生物识别数据一旦泄露，几乎没有“重置”的选项。

这也是AI招聘、AI风控、AI身份验证平台在当前阶段面临的最敏感风险之一：它们处理的并非普通用户行为日志，而是高密度、强身份属性的数据集合。一旦失守，后续风险不仅限于撞库、诈骗、勒索，还可能延伸至身份伪造、深度伪造训练、定向社工等更复杂的威胁。

TeamPCP在Telegram上的公开表述带有明显的挑衅意味：

这句话不仅是嘲讽。

它揭示了一个现实：今天许多企业对开源供应链安全的信任，建立在“上游默认可信”的前提之上。尤其是安全工具、CI/CD插件、包管理生态中的明星项目，往往被赋予更高权限，却没有获得同等强度的隔离、签名验证和行为监控。

于是，最吊诡的一幕出现了：企业为了提升供应链安全，大规模引入扫描器、自动化检查和依赖治理工具；而攻击者反过来利用这些工具的信任地位，将攻击投射到更深的层次。

这不再是单点漏洞，而是信任链的反噬。

公开信息显示，整个攻击链累计影响超过50万家企业身份，窃取了300GB以上压缩后的凭证。这组数字表明，Mercor只是被曝光的受害者之一，而非全部。

更值得注意的是，Lapsus$也被指与TeamPCP合作，正在拍卖相关数据。该组织过去曾攻击微软、英伟达、Okta，其风格一直非常明确：不仅获取数据，还善于将技术入侵与舆论放大、勒索施压、二次渗透相结合。

FBI网络部门助理主任Brett Leatherman也在LinkedIn上公开警告，未来几周应预期“更多泄露披露、后续入侵以及勒索尝试”。

换句话说，这起事件很可能尚未结束。

许多团队现在讨论AI安全时，仍停留在提示词注入、越权调用、模型幻觉等“应用层问题”上。但Mercor事件提醒我们，真正的重大风险其实存在于模型之外。

在今天的AI系统中，最该被重新定义为核心资产的，不只是模型本身，还包括连接模型的一整套供应链设施：包仓库、构建流水线、推理网关、密钥管理、日志平台、对象存储、身份系统。

这些地方一旦失守，模型越强大，放大的伤害越大。

尤其是在招聘、金融、医疗、教育等领域，AI已经开始吞噬大量高敏感度数据。过去互联网公司泄露的是邮箱、手机号和哈希密码；现在AI公司泄露的，可能是面部视频、证件扫描件、语音样本、行为标签、能力画像和跨平台调用凭证。

这不是“数据量更大了”，而是“数据的可滥用性更强了”。

第一，重新审视AI网关的安全等级。像LiteLLM这类组件，不能再按普通SDK或中间件来管理，而应按照高价值Secrets基础设施的标准进行治理，做到最小权限、密钥分域、实例隔离和快速轮换。

第二，将依赖安全管理从“漏洞扫描”升级到“发布链可信”。仅仅关注CVE已经不够，必须引入包签名、