2026 年 3 月 25 日，AI 网关库 litellm 的两个 PyPI 版本（1.82.7 和 1.82.8）被确认存在供应链攻击，恶意代码在包初始化时执行，用于窃取敏感凭据并外传至攻击者控制的服务器。任何使用这两个版本的开发者和企业需立即采取行动，本文提供完整的事件分析、危害评估与可落地的应急响应参数。

事件概述与技术背景

Litellm 是由 BerriAI 维护的 AI 网关库，主要用于统一接口调用 OpenAI、Anthropic、Azure OpenAI 等多种大语言模型 API，其周下载量超过 95 万次，在 AI 开发社区中应用广泛。这次供应链攻击直接针对其 PyPI 发布流程，通过入侵维护者的工作流，将恶意代码注入正式发布版本中。

根据 Snyk 与多家安全研究机构的分析，恶意代码被嵌入在包内的 litellm_init.pth 文件中。该文件是 Python 启动时自动执行的路径配置文件，攻击者利用这一机制实现代码的隐蔽执行。与传统的依赖混淆攻击不同，此次事件属于典型的维护者账户或 CI/CD 流程被入侵导致的供应链投毒。

恶意代码执行机制分析

恶意代码的执行流程设计精巧，主要包含以下几个阶段：

第一阶段为初始化触发。 当 Python 环境导入 litellm 包时，.pth 文件会被自动加载执行。攻击者将恶意脚本写入 litellm_init.pth，确保在任何代码调用之前先行运行，绕过常规的显式 import 检查。

第二阶段为凭据收集。 恶意代码针对大量敏感目标进行扫描，包括 SSH 密钥（~/.ssh/ 目录下的私钥文件）、云服务凭据（AWS_ACCESS_KEY_ID、GCP_SERVICE_ACCOUNT_KEY、AZURE_SUBSCRIPTION_ID 等环境变量和配置文件）、Kubernetes 配置（~/.kube/config）、Git 凭据（.git-credentials、SSH 配置）、以及所有当前进程的环境变量。

第三阶段为数据外传。 收集完成后，恶意代码将格式化后的凭据通过 HTTP POST 请求发送至攻击者控制的服务器。攻击者同时尝试在目标环境中建立持久化机制，以便后续进行横向移动。

值得注意的是，整个窃密过程在后台静默执行，不产生明显的日志输出或错误提示，常规开发者在使用过程中难以察觉异常。这使得该恶意代码具有较高的隐蔽性和持续性威胁。

受影响范围与危害评估

根据 PyPI 下载统计，litellm 1.82.7 和 1.82.8 在发布后的数小时内被大量自动安装工具和 CI/CD 流程拉取。根据社区反馈，受影响的环境至少包括：使用 pip install litellm 拉取最新版本的开发者机器、依赖自动升级的容器镜像、配置了 pip install -U litellm 的持续集成流水线，以及通过 transitive dependency 间接引入 litellm 的上层项目。

危害程度极高，原因在于：首先，被窃取的凭据类型覆盖了云基础设施、代码仓库和容器编排系统的核心认证信息，一旦被攻击者利用，可导致云资源被完全控制、代码仓库被篡改、以及容器集群被入侵；其次，攻击者可能已在多个目标环境中建立了持久化入口，具备随时进行横向移动的能力；最后，由于 AI 应用通常需要调用昂贵的模型 API，被窃取的 API Key 还可能导致额外的财务损失。

应急响应步骤清单

以下提供可直接执行的应急响应参数，建议按顺序执行：

第一步，立即冻结受影响版本。 在所有 Python 环境中执行版本回退：

pip install litellm==1.82.6

如果项目需要高于 1.82.6 的功能，建议等待官方发布安全修复版本后再升级。在此期间，务必将依赖声明中的版本范围严格限制为 litellm==1.82.6，避免任何自动升级行为。在 pip requirements.txt 或 pyproject.toml 中明确写入具体版本号是最直接的阻断手段。

第二步，全面排查环境中的恶意工件。 攻击者可能在受感染环境中留下了 .pth 文件作为持久化后门，需在 site-packages 目录下搜索异常文件：

find /path/to/site-packages -name "*.pth" -exec cat {} \; | grep -E "(requests|urllib|http|exfil|credential)"

同时检查是否存在可疑的 startup scripts 或被修改的 __init__.py 文件。

第三步，立即轮换所有可能暴露的凭据。 假设所有在受影响机器上运行的凭据已被窃取，包括但不限于：所有云服务（AWS、GCP、Azure）的 Access Key 和 Secret Key、GitHub/GitLab 等代码仓库的 API Token 和部署密钥、 Kubernetes 集群的管理凭据和 Service Account Token、模型 API 密钥（OpenAI、Anthropic、Azure OpenAI 等）、以及任何存储在环境变量中的业务敏感凭据。

第四步，审查 CI/CD 流水线。 检查 GitHub Actions、GitLab CI 或其他 CI 系统中的工作流配置文件，查找是否有未经授权的修改或新增的步骤。特别关注那些在构建过程中执行 pip install 的步骤，确保未引入额外的恶意依赖。

第五步，重建受感染环境。 对于无法确认是否被彻底清理的服务器和容器，建议直接销毁并重新构建，而非依赖修复。因为攻击者可能已在系统中部署了其他后门，逐一排查的成本往往高于重建。

长期供应链安全加固建议

此次事件暴露出 PyPI 生态中的供应链信任链脆弱性。从长期看，开发者和企业应在以下方面加强防御：

启用依赖校验机制。在生产环境中强制使用 pip 的 --require-hashes 模式，配合自建的 PyPI 镜像或私有索引源，只允许经过审核的包版本进入供应链。Hash 校验可以有效防止中间人篡改包内容，即使攻击者获取了 PyPI 发布权限，也无法在不匹配哈希的情况下完成安装。

实施依赖图审计。定期使用 pip-audit 或 Safety 等工具扫描项目依赖，识别已知漏洞和异常版本。对于直接依赖和间接依赖（transitive dependencies）均需纳入审计范围，本次事件中通过间接依赖引入 litellm 的上层项目同样受到影响。

强化发布流程安全。维护者账户应启用双因素认证，CI/CD 发布流程中的凭据需存储在专用的 secrets manager 中而非环境变量。建议引入代码签名机制，对 PyPI 包进行数字签名并在安装时验证签名完整性。

建立供应链安全监控。部署依赖监控服务（如 Snyk、Dependabot、Renovate）持续追踪项目依赖的安全状态，设置自动告警阈值。当发现新披露的漏洞或异常版本时，第一时间通过告警渠道通知安全团队。

资料来源： Snyk Vulnerability Database (SNYK-PYTHON-LITELLM-15762713), ThreatLandscape Security Research