AI网关LiteLLM 1.107.0安装包遭供应链投毒 启动即窃取云与AI开发凭据 官方Docker镜像受影响

    2026年10月21日，JFrog安全研究团队披露，广受欢迎的AI API网关LiteLLM的1.107.0版本恶意wheel安装包遭供应链投毒。恶意安装包加入了Python启动钩子，可在应用尚未导入LiteLLM时执行凭据窃取，并提供每小时检查一次的远程代码加载通道，受影响的还包括对应的官方Docker镜像。恶意载荷专门收集云服务及AI开发环境中的秘密信息。JFrog于10月22日更新称，厂商已控制事件，受污染的发布版本和镜像已被下架。这是LiteLLM近期第二次被劫持，凸显了AI开发工具供应链安全的严峻形势。

    根据JFrog安全研究团队的披露，此次攻击的技术细节如下：恶意攻击者成功劫持了LiteLLM 1.107.0版本的wheel安装包发布流程，在官方分发的安装包中注入了恶意载荷。与传统的供应链攻击不同，此次恶意载荷的植入位置极为隐蔽——它位于Python的启动钩子（startup hook）中，这意味着即使用户的应用尚未导入LiteLLM库，只要Python环境启动，恶意代码就会被执行。这种设计使得恶意载荷能够绕过基于代码库审查的安全检测：安装后的执行行为与代码仓库审查结果完全不一致，审查者检查源码归档时看不到恶意文件，但构建后的wheel包含这些文件。恶意载荷的功能包括两部分：一是凭据窃取，收集云服务（如AWS、Azure、GCP等）和AI开发环境（如OpenAI、Anthropic等模型API密钥）中的秘密信息；二是远程代码加载，恶意载荷每小时检查一次远程控制服务器，可以随时加载和执行任意远程代码，使攻击者能够长期控制受感染的环境。由于官方Docker镜像同样受到影响，使用容器部署LiteLLM的用户也面临风险。360威胁情报中心将该事件列为2026年10月17日至23日AI安全风险的首要事件。

    LiteLLM供应链投毒事件反映出AI开发工具链面临的系统性安全挑战。第一，AI开发工具是攻击者眼中的高价值目标：LiteLLM是AI应用开发中广泛使用的API网关，统一封装和转发各大模型提供商的API调用，开发环境中的LiteLLM实例通常持有访问大模型服务的密钥和云凭据，一旦被攻破，攻击者可以窃取模型访问密钥、窃取训练数据、滥用模型调用资源。第二，供应链攻击的检测难度极大：此次攻击将恶意代码植入Python启动钩子，且构建产物与源码不一致，传统的源码审查、依赖锁定等手段难以发现，安全团队需要将检查对象扩展到构建产物、安装包和运行时行为。第三，AI开发工具的更新速度快、生态复杂：LiteLLM等开源工具迭代频繁，用户往往自动更新到最新版本，而一旦某个版本被投毒，自动更新的用户会批量中招，影响面呈指数级扩散。第四，这是LiteLLM短期内第二次被劫持，表明AI工具链已经成为持续性攻击目标，类似的事件正在AI生态中频繁发生。第五，AI开发环境的凭据管理薄弱：许多开发者在环境中保存高权限的云凭据和模型密钥，且缺乏有效的隔离和轮换机制，一旦环境被投毒，凭据立即暴露。

    针对LiteLLM供应链投毒事件，安全专家建议采取以下防护措施。第一，立即核查是否安装了受污染的LiteLLM 1.107.0版本及其对应容器镜像：确认环境的安装来源和安装时间，隔离受影响的工作负载，移除恶意启动钩子。第二，轮换可能暴露的全部凭据：包括云服务凭据、开发环境凭据、模型API密钥，无论是否确认泄露都应轮换，因为恶意载荷在安装时即可能已窃取凭据，且无法确定窃取的数据范围。第三，检查AI调用记录和账单：攻击者可能利用窃取的密钥调用大模型API产生费用，检查异常调用和费用激增有助于发现和评估损失。第四，建立软件供应链安全基线：将AI开发工具的安装包纳入供应链安全管理，使用可信的软件源，验证安装包的哈希和签名，对构建产物与源码进行一致性校验，建立“安装行为与代码审查结果一致性”的检查机制。第五，加强对开发环境的凭据治理：不在开发环境中保存高权限凭据，使用密钥管理服务动态签发短期凭据，对凭据访问实施监控和审计，定期轮换。第六，关注AI工具链的安全情报：AI生态的安全事件频发，组织应持续跟踪AI开发工具（网关、框架、插件）的安全公告和威胁情报，第一时间响应高危事件。对于AI行业而言，LiteLLM事件再次证明：AI应用的安全不仅取决于模型本身，还取决于支撑模型运行的整个开发工具链，供应链安全必须成为AI安全体系的核心组成部分。