# 从Mercor攻击事件看LiteLLM供应链漏洞与企业纵深防御 > 深度剖析Mercor网络攻击事件与LiteLLM供应链漏洞的关联，揭示开源依赖链的攻击面并给出企业级防御参数与监控清单。 ## 元数据 - 路径: /posts/2026/04/02/litellm-supply-chain-vulnerability-enterprise-defense/ - 发布时间: 2026-04-02T15:02:40+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 2026年3月底，AI招聘平台Mercor披露遭受网络攻击，安全团队经溯源后发现攻击入口竞然来自其依赖的开源项目LiteLLM。这一事件并非孤例——它是2026年3月下旬针对全球开发者社区的大规模供应链攻击的一环。攻击者通过入侵CI/CD管道，将恶意代码植入LiteLLM的PyPI发布包，导致任何在特定时间窗口内通过pip安装该库的用户都面临凭证泄露风险。理解这起事件的攻击链、影响范围以及企业应采取的防御动作，是每一位依赖开源AI基础设施的工程师必须面对的课题。 ## 攻击链路：从Trivy到LiteLLM的级联沦陷 这起供应链攻击的起点并非LiteLLM本身，而是一个看似无害的依赖项Trivy。Trivy是一款开源安全扫描工具，广泛用于CI/CD流水线中检测容器镜像和依赖项的漏洞。2026年3月中旬，攻击者通过某种手段获取了Trivy的发布令牌，随后利用这个被攻破的入口，将恶意代码注入Trivy的发布流程。由于LiteLLM的安全扫描工作流恰好依赖Trivy进行依赖检查，攻击链条由此传导——当LiteLLM的CI/CD系统运行Trivy扫描时，实际上已经引入了被篡改的组件。 根据LiteLLM官方安全公告，攻击者最终成功绕过了官方CI/CD流程，直接向PyPI上传了两个恶意版本：v1.82.7和v1.82.8。这两个版本在2026年3月24日10时39分UTC上线，约40分钟后被PyPI官方下架。但就是这短暂的40分钟窗口，足以让全球数千个开发环境和CI/CD流水线中招。攻击的核心逻辑并不复杂：恶意版本的proxy_server.py文件中被植入了一段凭证窃取程序，该程序会在进程启动时自动运行，扫描宿主机的敏感信息并外发。 ## 恶意payload的技术剖析与影响范围 深入分析受污染版本的技术细节，有助于理解攻击的实际危害程度。恶意代码的设计显示了相当程度的隐蔽性和针对性。它首先会遍历目标系统的环境变量，提取所有以API_KEY、SECRET、PASSWORD、TOKEN等字符串开头的值；接着它会检查用户home目录下是否存在。ssh文件夹并读取其中的私钥文件；如果目标运行在Kubernetes集群中，它还会尝试读取/run/secrets/kubernetes.io/serviceaccount目录下的令牌文件。更进一步，代码会尝试调用云服务商AWS、GCP、Azure的元数据服务接口，窃取绑定在实例上的临时凭据。 完成信息收集后，恶意程序会将数据加密并通过HTTP POST请求发送至两个外部域名：models.litellm.cloud和checkmarx.zone。值得注意的是，models.litellm.cloud并非LiteLLM官方的域名，这正是最直接的入侵指标。LiteLLM在后续的安全公告中已将这两个域名列入IoC（Indicators of Compromise）列表，供企业进行全网排查。 这起攻击的影响范围远超LiteLLM直接用户。由于LiteLLM是许多AI代理框架和LLM编排工具的底层依赖，受污染版本可能作为传递依赖被间接引入无数项目。LiteLLM官方估计，受影响环境数量可能达到数万的量级。Mercor作为YC孵化的AI招聘明星公司，首当其冲地成为攻击目标，其内部系统可能已被攻击者深度渗透。 ## 企业级应急响应与根除方案 面对供应链攻击，时间就是安全。LiteLLM官方在事件曝光后数小时内完成了恶意包的下架，并发布了经过审计的安全版本v1.83.0。但企业仅仅升级版本远远不够，必须采取系统性根除行动。以下是经安全团队验证的标准化响应流程，建议按优先级依次执行。 第一优先级是确认受影响范围。企业应立即检查所有Python环境中LiteLLM的安装版本，最直接的方式是运行pip show litellm并核对版本号。如果版本显示为1.82.7或1.82.8，则该环境基本可以判定为已沦陷。对于大规模分布式系统，建议使用 LiteLLM官方提供的GitHub Actions和GitLab CI扫描脚本，输入组织名称即可自动化检索所有在受影响时间窗口内执行过pip install litellm的流水线作业。 第二优先级是凭证轮换。由于恶意代码设计为窃取各类敏感凭据，企业应假设受影响机器上的所有凭据已暴露。这不是过度谨慎，而是供应链攻击的默认假设。具体而言，需要轮换的凭据包括但不限于：所有云API密钥（AWS Access Key ID/Secret Access Key、GCP Service Account JSON、Azure Service Principal凭据）、数据库连接字符串、SSH私钥、CI/CD平台的操作令牌（如GitHub Personal Access Token、GitLab Access Token）、以及任何在环境变量中存储的第三方服务密钥。轮换应遵循先高权限后低权限的原则，先处理管理员账户和Production环境的凭据。 第三优先级是文件系统检查。恶意版本会在Python的site-packages目录下写入一个名为litellm_init.pth的文件，该文件会在任何Python进程启动时自动执行恶意代码。企业应使用以下命令在所有相关机器上检索该文件：find /usr/lib/python*/site-packages/ -name "litellm_init.pth"。如果发现该文件，必须在保留取证镜像后立即删除，并进一步排查是否存在其他持久化机制。 ## 构建面向未来的供应链安全纵深体系 LiteLLM攻击事件为依赖开源生态的企业敲响了警钟。传统的依赖管理思路——只要定期更新到最新版本就能保持安全——在这类供应链攻击面前几乎失效。企业需要从被动响应转向主动防御，建立多层防线。 在依赖引入层面，建议严格执行依赖版本 pinning 策略。所有项目必须使用精确版本号（如litellm==1.82.6）而非浮动版本（litellm>=1.82.0），避免自动拉取最新版本引入未审计代码。同时，企业应引入Software Bill of Materials（SBOM）机制，记录每个部署包的所有传递依赖，以便在类似事件发生时快速定位受影响系统。在CI/CD管道层面，工具链的版本同样需要锁定。企业应避免在构建过程中使用latest标签拉取Trivy、pip、docker等工具，改为使用经过安全审计的特定版本。此外，所有包管理器的发布流程都应启用双因素认证和签名验证，防止令牌泄露导致的非法发布。 在运行时监控层面，企业应部署网络流量分析系统，重点监控出站连接中的异常域名。本次事件中，models.litellm.cloud和checkmarx.zone作为恶意数据外发目标，属于典型的C2通信特征。企业可以在防火墙或代理层面设置域名黑名单，同时对任何试图连接非白名单域名的进程触发告警。环境变量的动态监控同样关键——如果生产环境中出现新增的敏感环境变量（如突然注入的API_KEY），应立即触发安全审查流程。 最后，供应链安全的长期解药在于零信任架构的落地。即使依赖项被攻破，零信任原则也能限制攻击者的横向移动。最小权限原则要求每个服务账户仅授予完成其功能所必需的最小权限集；网络分段则确保即便某一台机器沦陷，攻击者也无法直接访问核心数据库或密钥管理系统； secrets 加密存储（如HashiCorp Vault、AWS Secrets Manager）则保证即使获取了机器访问权，攻击者仍难以直接读取明文凭据。 LiteLLM供应链攻击不是第一起，也绝非最后一起针对开源生态的攻击。随着AI基础设施在企业生产中的权重日益提升，类似的攻击只会更加频繁和精准。Mercor的遭遇已经证明，即使是有顶尖工程团队支持的明星初创公司，也难以完全免疫供应链端的漏洞。企业需要从这起事件中汲取的教训，不是某个具体版本的告废，而是整个依赖消费模式的反思：当我们将关键业务逻辑托付给开源组件时，我们实际上也在继承那些组件的安全风险。唯有建立系统化的供应链安全治理体系，才能在未来的攻击浪潮中保持韧性。 --- **资料来源：** - LiteLLM官方安全公告（docs.litellm.ai/blog/security-update-march-2026） - TechCrunch报道（Mercor cyberattack coverage） ## 同分类近期文章 ### [微软终止VeraCrypt账户：平台封禁下的供应链安全警示](/posts/2026/04/09/microsoft-terminates-veracrypt-account-platform-lock-risk/) - 日期: 2026-04-09T00:26:24+08:00 - 分类: [security](/categories/security/) - 摘要: 从VeraCrypt开发者账户被终止事件，分析Windows代码签名的技术依赖、平台封禁风险与开发者应对策略。 ### [GPU TEE 远程认证协议在机密 AI 推理中的工程实现与安全边界验证](/posts/2026/04/08/gpu-tee-remote-attestation-confidential-ai-inference/) - 日期: 2026-04-08T23:06:18+08:00 - 分类: [security](/categories/security/) - 摘要: 深入解析 GPU 可信执行环境的远程认证流程，提供机密 AI 推理场景下的工程参数配置与安全边界验证清单。 ### [VeraCrypt 1.26.x 加密算法演进与跨平台安全加固深度解析](/posts/2026/04/08/veracrypt-1-26-encryption-algorithm-improvements/) - 日期: 2026-04-08T22:02:47+08:00 - 分类: [security](/categories/security/) - 摘要: 深度解析 VeraCrypt 最新版本的核心加密算法改进、跨平台兼容性与安全加固工程实践，涵盖 Argon2id、BLAKE2s 及内存保护机制。 ### [AAA 游戏二进制混淆：自研加壳工具的工程现实与虚拟化保护参数](/posts/2026/04/08/binary-obfuscation-in-aaa-games/) - 日期: 2026-04-08T20:26:50+08:00 - 分类: [security](/categories/security/) - 摘要: 解析 AAA 级游戏二进制保护中的自研加壳工具、代码虚拟化性能开销与反调试实现的技术选型。 ### [将传统白帽黑客习惯引入氛围编程：构建 AI 生成代码的防御纵深](/posts/2026/04/08/old-hacker-habits-for-safer-vibecoding/) - 日期: 2026-04-08T20:03:42+08:00 - 分类: [security](/categories/security/) - 摘要: 将传统白帽黑客的安全实践应用于氛围编程，通过隔离环境、密钥管理与代码审计，为 AI 生成代码建立防御纵深，提供可落地的工程参数与清单。