# Litellm 1.82.7 与 1.82.8 被植入恶意代码：PyPI 供应链攻击应急响应指南 > Litellm 1.82.7 和 1.82.8 版本在 PyPI 被植入恶意代码，通过 litellm_init.pth 窃取凭据。立即停用、审计依赖链、轮换密钥是当前最紧迫的措施。 ## 元数据 - 路径: /posts/2026/03/26/litellm-pypi-supply-chain-attack-response/ - 发布时间: 2026-03-26T00:01:37+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 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 环境中执行版本回退： ```bash pip install litellm==1.82.6 ``` 如果项目需要高于 1.82.6 的功能，建议等待官方发布安全修复版本后再升级。在此期间，务必将依赖声明中的版本范围严格限制为 `litellm==1.82.6`，避免任何自动升级行为。在 pip requirements.txt 或 pyproject.toml 中明确写入具体版本号是最直接的阻断手段。 **第二步，全面排查环境中的恶意工件。** 攻击者可能在受感染环境中留下了 `.pth` 文件作为持久化后门，需在 site-packages 目录下搜索异常文件： ```bash 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 ## 同分类近期文章 ### [微软终止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 生成代码建立防御纵深，提供可落地的工程参数与清单。