Mercor 也被 LiteLLM 这波带走了：AI 基建一旦中毒，倒下的不只是一个开源库
有些安全新闻看上去像‘某家公司被黑了’，但往深里看，你会发现真正出问题的不是那家公司，而是它脚下那层大家默认安全、默认顺手、默认不会翻车的基础设施。
Mercor 这次就是个很典型的例子。
根据 TechCrunch 的报道，AI 招聘创业公司 Mercor 已确认自己是 LiteLLM 供应链事故的受影响者之一，而且公司自己直接说了：他们只是“数千家受影响公司”里的其中一家。
这句话的信息量其实非常大。
因为它意味着，这已经不是‘某个开源项目被投毒’那么简单了。真正的现实是：AI 生态里那层负责接模型、管路由、控成本、串工作流的基础组件，已经开始具备和 npm、PyPI 头部包一样的爆炸半径。
先说人话版结论
这次事件最值得警惕的，不只是 Mercor 中招，而是下面这几件事同时成立：
- LiteLLM 是一个被大量团队拿来接各种模型的 AI 网关/中间层
- 恶意版本曾在 PyPI 上短暂出现
- 研究者统计显示，这两个问题版本在 46 分钟里被下载了 46,996 次
- FutureSearch 的分析指出，2,337 个依赖 LiteLLM 的 PyPI 包里，有 88% 的版本约束在当时都可能解析到中毒版本
- Mercor 现在确认，自己也是被这一波供应链事故波及的公司之一
换句话说，这不是一个库自己摔了一跤，而是一层 AI 基建打了个喷嚏，后面半条工具链都跟着发烧。
Mercor 的确认，为什么比“某包出事了”更严重
如果只是安全研究员说“这个包很危险”，很多团队还会下意识觉得：
- 也许只是实验环境
- 也许只是个别开发者机器
- 也许只是理论风险
但 Mercor 这种公司出来确认受影响，事情就不一样了。
它不是一个边缘项目，也不是一个没人在意的小团队。它本身就是 AI 产业链里相当核心的一环，既和大模型训练相关，也要处理大量业务流、人员流和平台数据。TechCrunch 还提到，Lapsus$ 随后声称拿到了 Mercor 数据，并放出了一些样本，里面包括看起来与 Slack 和工单系统有关的内容。
虽然现阶段公开信息还没把“LiteLLM 事故”和“后续数据被谁拿走、怎么拿走”完全拼成一张无争议的完整图，但有一点已经足够扎心：
一旦 AI 中间层被打穿，后面受伤的可能不是一个开发环境，而是真实业务系统。
LiteLLM 这次到底出了什么事
公开披露里，LiteLLM 的恶意版本主要是 1.82.7 和 1.82.8。
其中更狠的一个点在于，攻击不只是“装完以后你运行应用才会中招”，而是安装过程本身就可能触发恶意代码执行。FutureSearch 的分析提到，1.82.8 利用了 Python 的 .pth 机制，能在解释器启动时自动执行代码，甚至让 pip install 这一步自己就变成攻击触发器。
这也是为什么很多人看到这件事会头皮发麻：
- 你不需要手动跑一段可疑脚本
- 你不需要主动 import 某个危险模块
- 有时候你只是拉依赖、装环境、起服务
- 结果恶意逻辑已经先一步跑起来了
这类攻击最阴的地方，就在于它利用的是开发者最日常、最放松警惕的动作。
过去大家担心 npm；现在更该盯的是 AI 工具链
如果把这事只写成“又一个供应链安全事故”，其实有点低估它了。
因为 LiteLLM 不是传统意义上那种‘业务里顺手用一下的小工具包’。它所在的位置更像是 AI 时代的总线层：
- 上面接 OpenAI、Anthropic、Gemini 之类模型
- 中间做路由、鉴权、预算、日志、代理
- 下面接应用、Agent、MCP 服务、内部平台、自动化流程
这意味着什么？
意味着一旦这一层出问题，它影响的不只是某段功能代码，而是可能沿着整条 AI 调用链扩散。
以前一次包管理事故，可能主要影响单个应用。
现在一次 AI 基建事故，可能同时碰到：
- 开发机
- CI/CD
- Agent 工作流
- 模型代理层
- 企业内部密钥
- 云环境和 K8s 配置
FutureSearch 在后续分析里提到，被窃取的目标材料可能包括 SSH key、云凭证、.env、Kubernetes 配置等。这就已经不是“某个 prompt 写坏了”，而是实打实会进运维和生产事故范围的东西。
这件事最可怕的，不是 46 分钟，而是默认信任
46 分钟听起来很短。很多人会下意识觉得：
就半小时多一点，能有多大影响？
但问题在于，现在自动化太快了。
一个新版本只要上架，短短几十分钟里就可能被：
- 本地开发环境自动解析到
- Docker 构建重新拉取
- CI 新 job 安装进临时环境
- MCP 或 AI 工具通过
uvx、pip、npx这类执行器静默下载 - 没锁版本的上游库继续把问题带给下游用户
所以真正危险的，不是时间窗口有多长，而是默认信任 + 自动解析 + 高频重建环境 这三件事绑在了一起。
你会发现，AI 工具的丝滑体验，某种程度上也在放大供应链风险：越无感，越容易在出事时让人完全没感觉。
这不是“AI 特有风险”，但它会被 AI 放大
我不太喜欢把所有安全问题都神神叨叨写成“AI 新时代独有灾难”，那样很容易变味。
更准确的说法是：
LiteLLM 这类事故不是 AI 发明的，但 AI 生态会把它的传播效率、影响范围和隐蔽性一起放大。
原因很简单：
- AI 组件更爱接外部服务
- AI 工具链更依赖快速安装和实验
- Agent/MCP 场景更容易把本地环境、凭证和自动执行连在一起
- 很多团队还没把 AI 中间层按“高危基础设施”对待
于是就出现了一个很讽刺的现实：
大家一边聊 prompt injection、越权调用、Agent 乱操作；
另一边，真正先把很多人放倒的，可能还是最老派的依赖投毒。
对团队来说，接下来该补什么
如果你的系统里用了 LiteLLM，或者用了任何处在 AI 调用链中间层的位置组件，我觉得接下来最值得补的不是口号，而是这几件硬事：
- 锁版本，不要只写宽松范围：尤其是基础代理层、MCP 执行器相关依赖
- 把安装行为当执行面看待：
pip install、uvx、npx都别再当纯下载 - 让 CI 和开发机权限分层：别让安装依赖的环境天然拿满所有长期凭证
- 把 AI 基建组件纳入重点审计：模型网关、代理层、工作流执行器都该进高风险名单
- 优先采用更强的发布链保障：像 PyPI Trusted Publishers、签名、可验证制品链这些，真的该配上
- 事故后别只升级版本：如果你在时间窗口里装过问题版本，更合理的思路是按“凭证可能泄露”处理
说难听点，现在很多团队对 AI 工具链的安全态度，还停留在“它只是个开发辅助组件”。
但从这次事故看，很多所谓辅助组件，早就已经是生产系统的骨架了。
我的判断
Mercor 确认受影响这件事，最大的价值不是又给安全新闻多添一个受害者名字，而是它帮整个行业补上了一句很现实的话：
AI 基建出事时，后果不会停在开源社区讨论区里，它会一路顺着企业真实系统往下掉。
过去几年，大家总爱把 AI 产业理解成“模型层最重要”。
但越到今天我越觉得，真正决定系统稳不稳的，往往不是最会出风头的模型，而是那层安静地帮你接模型、转请求、控调用、串工作流的中间基础设施。
这层一旦中毒，倒下的就不会只是一个库。
很可能是一串你本来以为彼此独立、其实全都踩在同一块地板上的系统。