LiteLLM 发布流程遭劫持，恶意版本被植入窃密木马

开源 AI 网关项目 LiteLLM 的软件发布流程遭攻击者劫持，被植入窃密恶意代码的 1.107.0 版本于 10 月 21 日通过 Python 包索引 PyPI 和官方 Docker 镜像对外分发。LiteLLM 称恶意 Python 包在架约两小时后被移除，受影响的 Docker 镜像于当天晚些时候撤回或替换。

这是该项目今年第二次遭遇供应链攻击。攻击者使用与三个开发者账户关联的被盗 GitHub 凭据篡改发布工作流，将其重定向至攻击者控制的仿冒仓库。LiteLLM 表示事件已得到控制，使用其私有企业镜像仓库的客户未受影响。

恶意代码如何运行

据安全公司 Aikido 的分析，被篡改的包中捆绑的文件会在 Python 启动时自动执行，即使应用程序并未导入 LiteLLM 也会触发。这一机制意味着受影响范围不限于实际调用该网关的应用。

该恶意软件被设计用于从受感染系统中收集敏感信息，包括云凭据以及存放在 LiteLLM 数据库中的 API 密钥，攻击者因此可能获得超出该 AI 网关本身的服务访问权限。

Aikido 还指出，被篡改的包内含一个远程访问木马，会启动后台进程，每小时从攻击者控制的基础设施获取并执行代码。这使得攻击者能在最初的凭据窃取之后，继续在受感染系统上执行命令。

凭据来源与影响范围

在事件报告中，LiteLLM 称攻击者使用了与三个开发者账户关联的被盗 GitHub 凭据来操纵其软件发布流程。这些凭据使攻击者得以修改发布工作流，并将其重定向至攻击者控制的仿冒仓库。

LiteLLM 表示，攻击者可能从与该内部 LiteLLM 部署相关的日志中获取了这些凭据，该部署可经由互联网访问。公司还发现，Claude Code 在某些情况下会在响应中暴露 GitHub 认证令牌，而这些响应随后被 LiteLLM 记录。不过，攻击者最初如何访问该部署尚未查明。

受影响的 Docker 镜像包括以 latest、main-latest 和 main-stable 标签分发的镜像，这使在暴露窗口内拉取这些标签的部署同样面临风险。

企业层面的暴露面

Confidis 首席执行官 Keith Prabhu 表示，被攻陷的 LiteLLM 网关为攻击者提供了稳固的立足点，可能暴露的内容远不止 AI API 密钥。Aikido 指出，该恶意软件的目标包括 Kubernetes 服务账户令牌，以及与 GitLab、Jenkins 等 CI/CD 系统相关的机密信息。

后续是否发生进一步失陷，可能取决于受影响部署被赋予的权限及其可访问的凭据。IDC 信息与数据安全研究总监 Sakshi Grover 表示，AI 网关是有特权的企业基础设施，集中访问多个模型可以改善治理，但同时也会集中信任。

Grover 还表示，除凭据窃取外，被攻陷的网关可能扰乱依赖它的业务应用。IDC 于 2026 年 7 月开展的 Future Enterprise Resiliency and Spending 调查发现，全球受访企业中 95% 至少有一个由公司资助、具备代理能力的生产工作流。

清理不等于安全

恶意软件的远程访问组件可能在恶意包被移除后仍然活跃，这使判断受影响系统能否安全恢复变得更加复杂。Prabhu 表示，CISO 不应把这仅仅当作一次包清理工作。

他建议识别运行受影响包或容器镜像的部署，隔离可疑系统，并在使用可信软件重建之前保留取证证据。Grover 警告说，安全团队应避免在疑似受感染的启动 Python 或 pip，因为恶意软件的启动钩子可能再次执行。她建议在生产环境、开发者系统和 CI 运行器中识别受影响的包与容器镜像摘要。

Grover 表示，缺少指标并不能证明环境是干净的。Prabhu 建议检查日志，寻找持久访问或被盗凭据被滥用的迹象，并轮换受感染部署可访问的每一个机密，包括与云基础设施和开发流水线相关的凭据。Grover 还建议将 AI 使用遥测与云及身份审计日志关联，以识别可能的凭据滥用；异常的令牌消耗可能提示未授权活动，尽管攻击者也可能避免产生明显的支出增长。

第二次供应链事件

今年 3 月，该项目 Python 包的恶意版本曾被分发，LiteLLM 将那次事件与其发布流水线中使用的 Trivy 安全扫描器联系起来。

此后，LiteLLM 加强了发布流程，将发布迁移至私有仓库并引入签名 Docker 镜像。但公司表示，攻击者利用被盗 GitHub 凭据修改了发布工作流，该工作流随后对恶意软件进行了签名和发布。

这一事件显示，当攻击者攻陷发布流水线时，恶意代码可以穿过经过授权的软件签名流程。有效的数字签名可以验证制品自签名以来未被改动，但无法确认代码在签名时是否安全。Prabhu 表示，反复出现的供应链失陷表明，可信的源仓库并不能保证用户安装的包就是由该源构建的。他建议采用可验证构建来源的加密签名发布，并加强对发布凭据的保护。Grover 则建议企业在部署前检查分发的软件包和容器镜像，而不是仅依赖源仓库的完整性；她建议生产部署只使用经过验证的包和镜像摘要，并要求对发布工作流的变更进行独立审批。