LiteLLM 的公开发布流程遭到入侵，含有恶意代码的软件包和承载隔离运行环境的容器镜像曾在一段时间内被分发。在该时段安装或运行过这些发行物的用户，应清理环境，并更换主机曾可访问的秘密值。公司表示，面向企业客户的非公开发行物不受此次事件影响。
1. 受污染的软件包与镜像范围
据公司于 2026年10月21日发布的报告，PyPI 上 LiteLLM 1.107.0 的 wheel 安装包，即 Python 安装用压缩发行文件，共 7 个全部受到污染。恶意代码可窃取用于证明系统访问权限的凭证，并加载通过网络执行代码的远程代码执行工具。公司表示，先前版本安全，受影响的发行物已撤回。
容器方面，Docker Hub 和 GHCR 的 v1.107.0 与 latest 标签受到影响。标签是指向待下载镜像的名称标记。
main-latest 和 main-stable 标签也曾指向受污染的镜像。
GHCR 上除基础镜像外，litellm-database 和 litellm-non_root 镜像也受到影响。
官方 GitHub 的 1.107.0 源码标签中没有恶意文件，受污染的发行物是在攻击者控制的另一个仓库中构建的。
2. 按各仓库的暴露时间核对安装记录
公司报告中的时间均为 2026年10月21日 UTC，即协调世界时。
表：各仓库受污染发行物的发布、移除或确认时间
条件：2026年10月21日，以受影响的软件包和镜像标签为准
单位：UTC 时间
| 仓库 | 发布开始 | 移除或确认时间 | 结束时间的含义 |
|---|---|---|---|
| PyPI | 11:39:51 | 13:23 | 截至该时间已移除问题版本 |
| Docker Hub | 11:46:56 | 14:20 | 已移除受影响的标签和镜像变体，或将其重新指向经验证的正常发行物 |
| GHCR | 11:46:56 | 13:51 | 确认受影响标签不可用的时间，并非实际移除时间 |
各仓库完成清理的时间不同，应分别核对所用发行物的安装和运行记录，不能将 GHCR 的确认时间视为确定的暴露结束时间。
公司提醒未固定版本且在 11:39~13:23 安装的用户检查是否受到影响。
公司建议，若在 PyPI 的 11:39:51~13:23 时段安装了问题版本，或在 Docker Hub 的 11:46:56~14:20 时段运行了受污染的镜像，应视为环境已遭入侵。GHCR 的受影响标签在 13:51 已确认不可用，但实际移除时间并未确认。公司建议暂时固定到 1.106.2 或更早发布的明确版本。
3. 再次启动 Python 前先删除恶意文件
恢复应从在 shell 中删除恶意文件开始。因为在受影响的环境中启动 Python 可能再次执行恶意代码，而运行 pip 也会启动 Python。
按照公司建议，从每个受影响的安装目录中删除 cook.pth 和 cook.py。
同时删除 sitecustomize.py 及相关字节码缓存，即转换并保存 Python 代码的文件。
随后终止持有 /tmp/remote_code_loader.lock、正在独立运行的 Python 进程。清理完成后，使用以下命令检查安装版本。
pip show litellm之后固定到 1.106.2 重新安装。公司建议最好从头重建镜像和虚拟环境。
公司表示，若问题版本安装在可对外通信的主机，即联网计算机上，应视为信息已成功泄露。必须更换该主机曾可访问的实例和任务角色凭证（使用授予服务器或运行任务的访问权限的认证信息）、代理数据库中的提供商密钥及管理和虚拟密钥、数据库连接密码，以及进程环境中的秘密值。
公司建议在云活动记录服务 CloudTrail 中检查安装时间前后是否出现用于确认调用者身份的 GetCallerIdentity 调用。随后应检查相关角色的凭证是否曾在用户基础设施之外被使用。
4. 利用窃取的权限滥用正常发布流程
公司在 3月事件后，将管理发行文件的发布仓库转为非公开，并引入固定工作流和可信发布功能。公司还采取了禁止修改镜像标签、为镜像签名等措施。正常流程是从通过测试的提交（将代码变更打包记录的单位）构建发行物，再通过独立任务发布。
但在周一，为发布面向客户的错误修复版本，公司临时扩大了两名内部工程师的权限。公司表示，攻击者获取了三个开发者账户的 GitHub CLI 凭证，并使用其中组织所有者的令牌关闭保护设置、修改工作流。
攻击者让发布任务引用名称相似的 Berri-AI/litellm，而非正常仓库 BerriAI/litellm。根据公司时间线，第二个开发者账户的凭证被用于通过生产发布审批环节。被盗认证信息不仅用于修改源码，也用于批准发布。被篡改的工作流为受污染的发行物签名并发布，相当于在签名环节之前更改了构建路径。
公司表示，在特定情况下，Claude Code 的响应会包含用户的 GitHub CLI OAuth 令牌，即用于委托应用访问权限的认证值；若记录响应，令牌也可能留在内部服务日志中。公司认为，攻击者访问了暴露在互联网上的内部部署环境，并从日志中获取了令牌。
5. 撤回发行物后仍需用户完成的恢复工作
撤回发行物并重新指向正常镜像，是清理后续下载路径的措施。公司在调查期间将维护者凭证权限收回至必要的最低水平。用户则仍需另行清理并重建安装和运行环境，追踪并更换可访问的秘密值。
公司表示，尚未确定最初进入内部环境的路径，怀疑与近期修补的漏洞有关。此外，清理容器或临时文件可能抹去痕迹，因此不能仅凭没有恶意文件或泄露痕迹文件，就认定环境安全。
此次事件的用户应对，关键不在于发行物是否已被撤回，而在于彻底追踪暴露时段内的安装和运行记录，以及当时可访问的秘密值。