AI开发与招聘平台 Mercor 宣布，因 LiteLLM 依赖链被攻陷而遭网络攻击
多人工智能开发与招聘平台 Mercor 宣布，其系统被一次与开源项目 LiteLLM 供应链妥协相关的网络攻击波及。英文安全机构指出，恶意大版本（1.82.7 及 1.82.8）在 PyPI 上被注入远程执行与凭证窃取代码，可扫描环境变量、SSH 密钥、云凭证与 Kubernetes Token，并通过加密外传至攻击者控制域名，影响了使用这些版本的 AI 代理、开发与云平台。
技术分析显示，攻击者通过先期控制安全扫描工具 Trivy 与 CI/CD 管道，获取了 LiteLLM 项目的发布凭证，再将恶意代码伪装成“正常轮子”分发，形成“用安全工具撬动 AI 依赖—再用 AI 依赖撬动云凭证”的级联供应链攻击。
来源：公开信息
ABAB AI 解读
这起事件的“真正主角”不是某一家公司，而是“AI 通用网关式依赖”。LiteLLM 作为跨模型 API 路由中间层，天然集中大量 LLM 服务商、云平台与内部 API 的密钥，一旦被投毒，就成了“凭证实体化搬运通道”。Mercor 等 AI 平台正是这类“高度依赖中间层—密钥—云计算”的典型结构，所以被攻击者视为“一次敲击撬开多个云环境”的枢纽节点。
从安全结构看，这次攻击是“工具信任链”完全断裂的缩影：安全扫描工具（Trivy）本身被攻破，接着又被用于窃取 PyPI 发布权，最终把“发现问题的工具”变成“藏入漏洞的管道”。这意味着在当前典型的 DevOps 流程中，上游“安全”依赖竟然成了攻击者撬开“应用”与“云”通道的钥匙。
更深层看，这一连串妥协预示着“供应链安全战争”已经进入“中间层代理人”阶段：攻击者不再只针对终端应用，而是把“中间件、网关、工具包”当作“钩子基础设施”——只要这一个依赖被感染，成千上万的 AI 代理与云环境就自动成为“目标清单”。未来能在“工具—依赖—凭证—云”四层结构上设计出足够严格的隔离与权限边界的企业，才会真正拥有“能承受供应链妥协”的韧性，而不是依赖“某个开源包没有问题”。