2026年3月24日发生的Litellm供应链投毒事件，是近年影响范围最广、危害最隐蔽的AI生态供应链攻击。不同于常规的服务器漏洞入侵、Web漏洞爆破，这次攻击精准瞄准企业研发核心命脉——CI/CD构建环境。攻击者仅用40分钟的有效攻击窗口，就窃取了2488家企业的云密钥、AI大模型API密钥、K8s机密、Git凭据、数据库密码等核心敏感数据，近200TB企业机密数据泄露归档。
绝大多数企业的安全团队在事发初期完全无感，核心原因是攻击利用了Python生态底层机制、CI/CD环境默认高权限、研发流程无校验漏洞三重盲区。市面上多数碎片化解读只披露了事件表象，没有给出可直接落地的全量排查、处置、加固方案。
本文从攻击底层原理出发，完整还原攻击链路、恶意代码机制、风险判定标准，提供可直接复制运行的批量检测脚本、全维度资产排查清单、机密轮换优先级方案、CI/CD长效加固策略，帮助研发、安全运维团队彻底清零本次入侵风险，同时建立针对Python开源包供应链投毒的常态化防御体系。
1 事件核心原貌：打破认知的短窗口超大范围投毒
1.1 基础事件时间线与核心数据
本次攻击的核心特征是存活时间短、扩散速度快、窃取维度全、隐蔽性极强。攻击者没有利用复杂的0day漏洞，而是依托开源项目运维权限信任链的崩塌，完成合法渠道的恶意代码分发，这也是供应链攻击最难防御的核心痛点。
官方与安全厂商HudsonRock、CloudSEK复盘的精准时间线（UTC）如下：
2026年3月24日10:39，攻击者通过窃取的项目发布权限，在PyPI正式推送两个恶意版本：litellm 1.82.7、litellm 1.82.8；
10:39-11:19，共计40分钟有效攻击窗口，恶意代码持续抓取全球企业CI/CD运行环境机密并加密外传；
11:19之后，部分平台开始拦截恶意包，但PyPI官方未及时下架，恶意包持续公开存活至13:40左右，总公开时长超3小时；
事件收尾统计数据：关联有效企业域名2488个、抓取CI运行时快照118829条、泄露文件433909份、泄露数据总容量153TB-195TB。
很多团队存在认知误区：攻击窗口只有40分钟，是不是影响范围有限？真实情况完全相反。Litellm作为AI生态刚需网关工具，月PyPI下载量高达9500万，几乎所有中大型AI研发企业、AI应用创业公司、集成大模型的传统软件企业，均在CI流水线、测试环境、生产环境依赖该工具。
40分钟的有效执行时间，足以让全球海量自动化构建任务完成依赖拉取、代码执行、机密窃取。自动化CI流水线的高频调度特性，让短时间投毒的杀伤力被指数级放大。
1.2 本次攻击区别于普通漏洞的核心差异
常规网络攻击，大多是攻击者主动扫描、探测、入侵目标服务器，存在明显的攻击行为日志、访问记录，安全设备可以通过规则拦截、告警。本次Litellm供应链投毒，完全规避了传统安全防护体系的检测逻辑。
第一，攻击载体为官方正规渠道分发的开源包。恶意版本通过PyPI官方审核上架，属于「合法来源、恶意内容」，防火墙、WAF、入侵检测系统不会对正常包安装行为产生告警。
第二，触发机制无感知。恶意代码依托Python底层.pth机制实现自动执行，不需要开发者手动调用、不需要业务代码导入，只要安装恶意包、启动Python进程，后门就自动运行。研发人员、运维人员全程无操作感知。
第三，攻击目标为内存级环境变量。恶意代码只抓取当前CI运行时、构建机内存中的环境变量机密，不会落地恶意文件到磁盘、不会修改系统核心配置，常规病毒查杀、木马检测工具无法识别异常。
第四，权限天然充足。绝大多数企业CI/CD Runner、构建机默认配置最高权限，持有云平台密钥、集群权限、代码仓库权限，攻击者一次抓取即可获得全站核心资产。
2 完整攻击链路与底层技术原理
2.1 端到端攻击流程
本次攻击不是单点投毒，而是完整的权限窃取、包投毒、数据窃取、数据外传闭环链路，每一个环节都精准利用了开源项目运维和企业研发流程的通用漏洞。我用完整流程图还原攻击者的操作逻辑，方便大家定位自身流程的薄弱点。
整个链路没有任何高强度破解、漏洞利用，全程依托「开源项目权限管理混乱+企业依赖不锁版本+CI环境权限泛滥」三大行业通病。这也是该事件具备极强复用性的原因，同类攻击可以复刻到任意热门Python开源项目。
2.2 上游权限失守核心原因
很多人疑惑，Litellm官方项目为何会被上传恶意版本？核心问题不在Litellm项目本身，而在其CI/CD流水线依赖的开源工具Trivy。
Trivy是全球通用的容器、代码漏洞扫描工具，Litellm官方长期将其作为流水线必备依赖。攻击者通过攻破Trivy项目的运维权限，横向获取了Litellm项目的流水线配置、密钥变量，最终盗取了可直接推送版本至PyPI的发布Token。
这套Token具备项目最高权限，可以无审核上传任意版本的安装包，PyPI平台仅校验账号权限，不校验代码内容合法性。这就导致攻击者可以直接替换官方包内容，实现完全无感的供应链投毒。
2.3 恶意后门核心技术原理（.pth机制）
本次攻击最关键的技术核心，是Python的site-customize .pth 文件自动执行机制，这也是绝大多数研发和安全人员的知识盲区。
正常Python包的代码，必须通过import导入后才能执行，开发者可以通过代码审计、依赖扫描发现异常调用。但.pth文件是Python解释器的启动加载文件，存放于site-packages目录下。
Python启动时，会自动遍历site-packages下所有.pth后缀文件，读取并执行文件内的Python代码，无需业务代码导入、无需手动触发，只要Python进程启动，后门即刻运行。
攻击者在恶意版本中植入自定义litellm_init.pth文件，文件内置完整的环境变量扫描、机密抓取、加密外传逻辑。无论企业是手动安装、脚本安装、CI自动化安装，只要安装成功，后续所有Python进程都会触发后门。
后门执行后会静默遍历当前系统、CI Runner的全部环境变量，匹配所有主流云厂商密钥、大模型API密钥、仓库Token、数据库密钥、K8s Secret关键字，抓取完成后进行AES加密，批量上传至攻击者控制的models.litellm.cloud域名，全程无控制台输出、无磁盘日志残留。
2.4 泄露资产完整覆盖范围
本次泄露并非单一类型数据，而是覆盖企业研发、运维、AI业务的全维度核心机密，所有存储在环境变量中的敏感数据都会被批量抓取，具体分类如下：
云厂商核心凭据：AWS AccessKey/SecretKey、Azure订阅密钥、GCP服务账号密钥、阿里云/腾讯云AccessKey，这类密钥大多具备长期有效、高权限特性，一旦泄露可直接接管企业云资源。
AI业务核心资产：OpenAI、Anthropic、讯飞、文心一言等全平台大模型API Key，攻击者可盗用企业算力、产生高额账单、窃取企业私有AI微调数据。
研发流水线凭据：GitLab/GitHub/Gitee私人Token、CI/CD流水线登录令牌、PyPI/NPM私有仓库发布密钥，可导致代码泄露、恶意代码二次投毒、私有包篡改。
运维基础设施凭据：SSH私钥、Kubernetes集群Secret、节点访问密钥、Docker仓库登录凭证，可直接入侵企业服务器、容器集群，实现内网横向移动。
业务底层凭据：数据库账号密码、Redis/MQ访问密钥、业务接口签名密钥，直接引发数据泄露、数据篡改、业务劫持风险。
3 企业风险精准判定标准
很多企业目前处于两个极端：要么过度恐慌，无条件轮换所有密钥；要么心存侥幸，认为自己没有风险。本节给出精准、可落地的风险判定标准，满足任意一条即可判定为受影响，必须立即处置。
3.1 时间维度风险判定
在2026年3月24日 10:39 - 16:00 UTC时间段内，执行过任意Litellm安装操作的环境，全部存在被入侵风险。这个时间段覆盖了恶意包上架、有效攻击、下架前的全周期。
需要注意，不止手动安装，自动化行为全部包含在内：CI流水线自动构建、Docker镜像构建、服务器自动化部署、本地开发环境依赖更新。
3.2 版本维度风险判定
仅两个版本存在恶意后门：litellm1.82.7、litellm1.82.8
1.82.6及更早稳定版本、官方后续修复后的新版本无此后门风险。企业只要在依赖文件、构建脚本中拉取过这两个版本，无论是否显性使用Litellm功能，都会触发后门执行。
3.3 依赖链路风险判定
显性依赖和隐性传递依赖都存在风险。部分项目没有直接安装Litellm，但依赖的AI封装框架、LLM开发工具、智能问答组件间接依赖Litellm，会被动拉取恶意版本，同样会被植入后门。
3.4 环境风险优先级划分
高危环境：生产CI/CD Runner、线上构建服务器、持有云高权限密钥的自动化环境，泄露的机密具备长期利用价值。
中危环境：测试环境流水线、测试服务器，存在测试账号、测试密钥泄露风险，可能牵连生产权限体系。
低危环境：本地开发机，仅泄露个人开发凭据，无集群和云资源高权限，但仍需轮换密钥、清理后门。
4 全环境恶意文件检测脚本（可直接复制执行）
本次入侵无明显系统异常日志，唯一精准检测特征是系统site-packages目录下的litellm_init.pth文件。我编写了跨平台批量检测脚本，支持Linux、MacOS、Python虚拟环境，可一键扫描所有Python环境，精准定位恶意文件。
4.1 一键批量检测Shell脚本（Linux/MacOS）
#!/bin/bash # Litellm 恶意后门一键检测脚本 echo "===== 开始扫描Litellm恶意.pth后门文件 =====" # 扫描系统全局Python环境 find /usr/local/lib /usr/lib -name "litellm_init.pth" 2>/dev/null # 扫描当前用户Python环境 find ~/.local/lib -name "litellm_init.pth" 2>/dev/null # 扫描所有虚拟环境 find . -name "venv" -type d 2>/dev/null | while read venv; do find "$venv" -name "litellm_init.pth" 2>/dev/null done echo "===== 扫描结束，存在文件则代表环境已被投毒 =====" # 检测已安装恶意版本 echo -e "\n===== 检测恶意Litellm版本 =====" pip list | grep -E "litellm\s+1.82.7|litellm\s+1.82.8" pip3 list | grep -E "litellm\s+1.82.7|litellm\s+1.82.8"使用方式：新建scan_litellm.sh文件，赋予执行权限后全局运行，可扫描服务器、构建机所有Python环境。
4.2 Python跨环境检测脚本（全平台通用）
import site import os def check_litellm_backdoor(): # 获取所有Python站点包目录 site_paths = site.getsitepackages() backdoor_file = "litellm_init.pth" found = False print("开始扫描Python环境后门文件...") for path in site_paths: file_path = os.path.join(path, backdoor_file) if os.path.exists(file_path): print(f"【发现恶意文件】{file_path}") found = True if not found: print("【安全】未检测到Litellm恶意后门文件") if __name__ == "__main__": check_litellm_backdoor()该脚本适配Windows、Linux、MacOS，可直接在开发机、服务器、CI节点运行，适配所有Python版本。
4.3 恶意文件清理命令
检测到恶意文件后，执行以下命令一键清理，并卸载恶意版本：
# 卸载恶意版本 pip uninstall -y litellm==1.82.7 litellm==1.82.8 pip3 uninstall -y litellm==1.82.7 litellm==1.82.8 # 批量删除恶意pth文件 find / -name "litellm_init.pth" -delete 2>/dev/null5 企业分级应急处置实战方案
检测出风险后，禁止盲目操作，必须按照「隔离-清理-轮换-审计-加固」的顺序执行，避免处置不当导致二次风险。本节为可直接落地的企业级处置流程，适配中小团队、中大型企业研发体系。
5.1 第一步：环境紧急隔离
立即暂停所有项目的CI自动构建、镜像构建、自动化部署任务，阻断恶意代码持续执行和数据泄露通道。
对所有构建机、CI Runner节点、测试服务器进行网络隔离，限制节点对外出站访问，防止剩余未外传的机密数据继续泄露。
登记所有3月24日前后执行过部署、构建任务的节点、账号、流水线，建立风险资产台账。
5.2 第二步：依赖版本清零与回退
全局卸载所有恶意版本Litellm，禁止使用无版本锁定的安装命令。所有项目的requirements.txt、pyproject.toml、Dockerfile必须固化安全版本。
安全版本选择：优先使用1.82.6稳定版，或官方后续修复的最新正式版本，终身规避1.82.7、1.82.8两个版本。
禁止写法：pip install litellm、pip install litellm>=1.80模糊版本匹配
标准安全写法：pip install litellm==1.82.6精准版本锁定
5.3 第三步：机密凭据分级轮换（核心关键）
凭据轮换不能一刀切，按照风险高低分级执行，优先轮换可被攻击者直接利用的高权限资产，我整理了企业优先级执行清单，按顺序落地即可。
一级优先级（立即轮换，0延迟）：所有云厂商AccessKey、云服务账号密钥、K8s集群全部Secret、核心数据库密码、AI大模型全局API Key。这类密钥泄露后，攻击者可直接接管业务、盗取数据、产生巨额账单。
二级优先级（24小时内完成）：Git仓库Token、CI/CD流水线登录凭据、PyPI私有仓库发布密钥、Docker镜像仓库密钥。防止攻击者篡改代码、投毒二次传播。
三级优先级（72小时内完成）：开发机SSH私钥、测试环境凭据、业务接口密钥、缓存中间件密码。清理全环境弱凭据、过期凭据。
5.4 第四步：全维度行为审计
轮换凭据后，必须完成行为审计，确认攻击者未利用泄露凭据进行非法操作。
云平台审计：查看所有云资源异常登录、异常API调用、密钥异地登录、资源创建删除记录。
代码仓库审计：查看近期陌生IP登录、代码提交、分支合并、仓库克隆记录。
CI流水线审计：核查所有历史构建日志，确认是否存在恶意代码执行、异常文件上传行为。
业务日志审计：排查AI接口调用、数据库访问、外网出站流量异常。
5.5 第五步：环境全面加固
单次处置无法杜绝同类风险，必须从研发流程底层加固，修复本次暴露的所有漏洞。具体加固方案在本文第七章详细展开。
6 攻击底层架构与风险溯源
为了从根源防御同类供应链攻击，我们需要理清本次攻击的信任链崩塌逻辑。开源生态的信任体系，是建立在「上游项目可信、发布权限可信、依赖流程可信」三者之上，本次攻击直接击穿了整条信任链。
绝大多数企业默认信任PyPI、NPM等官方源的所有包，默认所有开源项目的迭代版本安全，这种无条件信任的研发模式，是供应链攻击泛滥的核心根源。
Python生态的特殊性进一步放大风险：包安装机制宽松、自定义启动文件无校验、依赖版本管理松散、虚拟环境隔离不彻底，让后门的隐藏性、传播性、执行成功率达到顶峰。
而CI/CD环境的权限设计缺陷，成为攻击的终极突破口。企业为了保证部署流程顺畅，普遍给Runner、构建机配置超级管理员权限、长期有效密钥，一旦被投毒，攻击者可以一次性获取企业全站最高权限资产。
7 长效防御：CI/CD与Python供应链安全加固方案
本次事件不是孤立事件，未来AI开源项目、Python通用工具的供应链投毒攻击会持续爆发。本节给出可落地的常态化加固方案，覆盖依赖管理、CI流程、权限管控、检测机制四个维度，彻底规避同类风险。
7.1 依赖管理体系加固
废弃所有模糊版本依赖规则，所有项目强制精准版本锁定。禁止使用大于、小于、匹配最新版本的动态依赖写法。
开启依赖哈希校验，所有第三方包必须校验sha256哈希值，防止官方源被篡改、中间人投毒。
定期扫描依赖供应链风险，重点关注高频更新、高下载量、CI流水线刚需的开源工具，这类项目是攻击者的首选目标。
区分生产、测试、开发依赖，生产环境仅保留核心依赖，最小化依赖攻击面。
7.2 CI/CD流水线安全加固
实现CI环境权限最小化，构建节点、Runner节点禁止存储长期有效密钥，全部替换为短时动态凭证，过期自动失效。
拆分构建、部署、推送权限，单一CI节点只保留单一功能权限，避免单点沦陷导致全站泄露。
开启流水线出站流量管控，构建环境禁止主动外网上传未知文件、未知加密数据，拦截异常数据外传行为。
所有构建操作留痕审计，记录依赖安装日志、Python进程启动日志、文件变动日志，实现风险可追溯。
7.3 恶意代码检测机制加固
新增Python.pth文件专项检测规则，所有CI构建前自动扫描站点目录，发现未知.pth文件直接终止构建并告警。
接入开源包静态代码扫描，检测包内隐藏的环境变量抓取、外网数据上传、恶意进程启动逻辑。
定期全量扫描服务器、开发机、虚拟环境，排查隐性后门文件，建立常态化扫描机制。
7.4 密钥凭据体系加固
废弃静态环境变量存储密钥的方式，接入密钥管理平台（KMS）、动态密钥服务，业务运行时实时拉取密钥，不落地、不常驻环境变量。
所有密钥分级管控，区分开发、测试、生产环境密钥，禁止跨环境密钥复用。
开启密钥异常使用告警，异地调用、高频调用、非常规IP调用自动拦截告警。
8 事件复盘与行业启示
Litellm 40分钟超大规模泄露事件，给整个AI研发行业敲响了警钟：供应链安全已经取代传统服务器漏洞，成为企业最大的安全风险点。传统安全防护思路只关注外部入侵，完全忽略了研发流程内部的信任崩塌。
开源工具不再等于安全工具，官方渠道不再等于可信渠道。攻击者已经从「攻击企业服务器」转向「攻击企业依赖的开源生态」，以更低的成本、更广的范围、更隐蔽的方式窃取企业核心数据。
CI/CD流水线是现代软件企业的核心命脉，也是供应链攻击的终极靶场。绝大多数企业的研发自动化流程，都是在牺牲安全换取效率，高权限、无校验、无审计的流水线，一旦遭遇投毒就是毁灭性的数据泄露。
对于所有AI研发企业而言，Litellm这类基础网关工具属于刚需依赖，无法彻底弃用，唯一的出路就是建立自主可控的依赖校验、环境检测、权限管控体系，不再被动信任开源生态。
互动提问
1、你的项目是否还在使用模糊版本的Litellm依赖，没有做精准版本锁定和哈希校验？
2、你们公司的CI/CD构建环境是否还在存放长期有效云密钥、业务密钥？欢迎在评论区留言交流加固方案。