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）
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。