2026 年 3 月 24 日,Python AI 生态主题基础组件 LiteLLM 遭逢 PyPI 供给链投毒,多多开发者照常执行pip install litellm,却不知装置的并非通常开源依赖,而是一把可直插云环境、K8s 集群、CI/CD 流水线、SSH 密钥库甚至数据库的 “全能钥匙”。
Python AI 作为月下载量超 9500 万、单日下载量达 3408615 次的 AI 基础设施 “总线层” 组件,这次投毒事务并非孤立的开源包挂马,而是针对 AI 生态的高成熟度供给链攻击,更是给所有企业敲响了数据安全与开源依赖治理的警钟。
一、为何 LiteLLM 投毒,杀伤力远超通常开源包?
面对开源包投毒,好多人的第一反映是 “卸载沉装即可”,但 LiteLLM 的特殊行业定位,让这次投毒的杀伤力呈指数级放大 —— 它并非边缘工具库,而是大量 AI 利用出产环境中接入多模型、多供给商、多网关战术的统一入口,能将 OpenAI、Anthropic、Google 等各类模型接口抽象为统一 API,是好多 AI 系统中 “所有密钥城市经过” 的主题地位。
这意味着,LiteLLM 被投毒后,攻击者接触的不是通常机械,而是存放着云平台 API 密钥、数据库配置、CI/CD token 的高价值环境,蕴含企业内部 Agent 执行环境、衔接内部知识库的自动化服务、带 K8s service account token 的容器节点等。攻击者无需逐个黑进企业,只需传染这个全行业高度信赖的基础依赖,就能让企业自动将后门带回出产环境,利用 “软件信赖” 实现规;セ,这也是供给链攻击远比通常缝隙更具威胁的主题原因。
二、深度拆解:LiteLLM 供给链投毒的主题作案手法
这次 LiteLLM 投毒事务的主题作案手法,突破了传统开源包恶意代码注入的通例模式,且两个恶意版本的攻击方式层层升级,更具荫蔽性,官方已确认安全版本回退至 1.82.6,且恶意代码仅存在于 PyPI 颁布物中,上游 GitHub 仓库无异常,或许率是颁布链路被劫持、守护者凭证被盗所致。
1.82.7 版本
导入即触发:恶意代码以 base64 编码载荷暗藏在litellm/proxy/proxy_server.py中,?楸坏既胧奔纯讨葱,企业只有运行有关?榛蛳钅科舳钡既敫寐呒,就会直接中招;
1.82.8 版本
装置即种下 “定使亘弹”:新增litellm_init.pth文件,利用 Python 诠释器启动时自动处置.pth文件的机造,实现无需手动 import,只有 Python 过程启动,恶意逻辑就可执行,从 “运行时中沼妆 升级为 “装置后整个 Python 环境被劫持”,直接踩穿了 Python 运行时的信赖模型。
三、全域凭证窃取,直指企业数字基础设施节造权
本次攻击最主题的威胁,在于其窃取指标的全域覆盖性与高价值性。据 BleepingComputer、Endor Labs、OX Security 等机构公开分析,恶意 payload 构建了齐全的敏感资产采集系统,覆盖企业全链路主题凭证,蕴含但不限于:
SSH 密钥与配置文件
AWS / GCP / Azure 云凭证
Kubernetes token 与集群 secrets
.env 及其变体文件
数据库凭证和配置
TLS 私钥
CI/CD secrets
加密钱币钱包有关数据
机械环境信息,如 hostname、whoami、uname -a、printenv 等窥伺信息 (BleepingComputer)
好多人将这类窃密攻击误会为 “偷账号”,但在云原生与 AI 工程系统中,攻击者现实篡夺的是整家公司数字基础设施的节造权:窃取云厂商凭证可直接读写存储、调度算力、遍历密钥;窃取 K8s Secret 能收受集群服务与通讯;泄露.env文件等同于露出创业公司主题密钥(支付、数据库、模型 API、第三方 SaaS 等);盗取 CI/CD Token 则会传染构建与颁布流程,实现悠久化入侵。性质上,这并非顺手牵羊,而是工业化批量窃取开发、云、容器与自动化流程中的高价值凭证。
四、这不是单点木马,而是一条齐全的攻击链
这次 LiteLLM 投毒事务之所以让整个开源生态严重,并非单案所致,而是该事务与攻击组织TeamPCP的陆续供给链作案链高度关联,该组织此前已参加 Trivy、Checkmarx/KICS 等开源工具的供给链攻击,LiteLLM 官方也确认这次事务与 Trivy 安全扫描依赖有关,且已实现所有守护者账号轮换。
这意味着,攻击者并非专门盯上 LiteLLM,而是将指标对准了开源生态上游的构建与颁布链路:先攻下高信赖度的安全扫描器、CI/CD 工具等上游组件,再借助下游项主张自动化流程和颁布凭证实现风险扩散,最终将习染面从一个工具扩大到整个生态链。
现代软件生态是相互嵌套的 “依赖丛林”,一个安全扫描器衔接 GitHub Action,一个 Action 衔接项目颁布流水线,一个流水线衔接 PyPI 等仓库,一个基础库又衔接数十万开发机和服务器,攻击者真正攻击的,是现代软件工业的 “复用与自动化结构自身”。
五、供给链攻击已从个案升级为生态连锁风险
LiteLLM 事务虽性质恶劣,但若仅为孤立案例,尚不及以令整个开源生态高度严重。真正令人警惕的是,它并非个案,而是统一攻击组织的系列行动。BleepingComputer、Snyk、The Hacker News、Endor Labs 等多家机构均证实,这次事务与 TeamPCP 组织有关,该组织此前已牵扯 Trivy、Checkmarx/KICS 等多起供给链攻击。LiteLLM 官方 issue 也明确指出,本次入侵与 Trivy 安全扫描依赖有关,且已全数轮换守护者账号。
这批注攻击者指标并非 LiteLLM 自身,而是上游更宽泛的构建与颁布链路。其典型模式是:先攻下高可信工具或 CI/CD 环节,再借助下游项主张自动化流程与颁布凭证扩散,将单点习染放大至整个生态链。
如今软件早已不是独立项目,而是高度嵌套的依赖丛林:安全扫描器关联 GitHub Action,Action 关联颁布流水线,流水线关联 PyPI/NPM/ 镜像仓库,基础库又关联数十万开发与出产环境。攻击者真正对准的,是现代软件工业的复用与自动化系统自身。当效能高度依赖默认信赖的自动装置、更新与颁布,供给链攻击便获得了极强的扩散杠杆。
六、从密钥暴增到权限失守,AI 供给链的底层安全;
2018 年产生此类事务已属严沉,放到 2026 年则风险倍增,主题原因是当下软件环境,尤其涉及到 AI 领域,的密钥密度呈爆炸式增长。从前通常 Web 服务仅需少量密钥,而如今一个 AI Agent 项目会同时集成多类模型密钥、向量库凭证、各类 SaaS 权限、云平台令牌、内部工具接口等大量敏感配置,相当于承载了一整套可编程的组织权限能力。
这正是 LiteLLM 事务的标志性意思:攻击者已意识到,AI 基础设施是高密度凭证、高权限自动化、高价值数据入口的集中体。一旦 AI 基础库遭逢供给链传染,攻击者获取的不只是本地 SSH 密钥,还可能渗入企业内网、节造审批与颁布流程、窃取模型预算与客户数据,甚至直接管受 Agent 工具挪用权限。
因而,LiteLLM 事务绝非单一安全变乱,而是明确信号:Agent 安全已进入默认高危阶段。未来 AI 安全不能只聚焦提醒注入、越权、幻觉等表层问题,更要直面底层风险:Agent 所依赖的组件、构建方、颁布权限,是否早已被传染的工具链波及?
七、事务警醒:警惕pth机造无感中毒
这次事务中,1.82.8 版本的.pth文件机造,堪称 “无感中毒” 的教科书式演示,也突破了企业对开源依赖防护的传统认知 —— 好多企业以为 “只有不执杏注不 import,被传染的开源包就无风险”,但.pth机造让恶意代码的执行脱离了业务代码挪用的约束。
.pth文件的可怕之处,在于其触发的前置性与荫蔽性:
触发无差距:无需业务代码显式引用,任何启动 Python 的剧本、测试、构建步骤、自动化工作,都可能触发恶意逻辑;
审计难发现:传统代码审计仅关注业务代码中的显式导入,而.pth的恶意行为产生在业务逻辑执行之前,极易被忽略;
习染领域广:在共享 Python 环境、CI Runner、镜像构建节点等场景中,只有装置过该版本,后续所有 Python 过程都可能被传染。
这也让行业意识到:装置被传染的依赖自身,就已经足够危险,开源依赖的安全防护,必须从 “运行时检测” 前移至 “装置前审计 + 全性命周期监控”。
八、LiteLLM 事务垂危措置措施
若是企业的开发环境、出产环境、CI/CD 流水线等任何场景使用过 LiteLLM,必要拉群执杏注即刻落地的垂危措置措施,KY开元结合行业安全实际,对每一步操作做落地化补充:
第一步:全场景排查恶意版本
通过pip show litellm、pip freeze | grep litellm号令,排查是否装置 1.82.7、1.82.8 版本,不仅要查线上服务,更要覆盖开发者本地环境、CI/CD runner、构建镜像节点、数据科学笔记本、K8s 节点、自动化剧本运行机等所有含 Python 运行时的环境;
第二步:立即回退至安全版本
执行pip install litellm==1.82.6沉装安全版本,同时对所有依赖 LiteLLM 的项目进行版本锁定,预防自动拉取最新版本;
第三步:全面排查悠久化攻击痕迹
沉点查抄~/.config/sysmon/sysmon.py、/tmp/pglog、/tmp/.pg_state等文件,排查是否存在假装成 “System Telemetry Service” 的 systemd 用户服务,同时查抄未知自启动项、暗藏目录及到checkmarx.zone、models.litellm[.]cloud的可疑出站衔接;
第四步:深度审计 K8s 集群安全
若 AI 服务运行在 K8s 环境,沉点审查kube-system定名空间中的未授权 Pod/daemonSet/Job,排查高权限 service account 异常使用、节点层面可疑容器、镜像拉取源及执行号令异常,阻断横向移动风险;
第五步:全量轮换敏感凭证
这是最主题的一步,立即轮换所有敏感资产凭证,蕴含 SSH 密钥、云平台(AWS/GCP/Azure)凭证、K8s secrets、.env 文件中所有变量、数据库密码、TLS 私钥、CI/CD token、第三方 SaaS API 密钥等,做到 “无一遗漏”;
第六步:复盘依赖引入链路
查清 LiteLLM 是直接装置还是通过上层依赖间接引入,查抄是否存在>=无上限版本约束,梳理哪些 CI 工作会自动拉取最新依赖、哪些镜像构建未锁定哈希,从源头堵截恶意依赖的引入蹊径;
第七步:隔离受传染环境
对确认装置过恶意版本的开发机、服务器、容器节点进行网络隔离,预防其持续与企业内网主题资产通讯,预防风险进一步扩散;
第八步:发展全环境安全扫描
利用企业级安全扫描工具,对所有出产环境、开发环境进行全面的恶意代码扫描与缝隙检测,排查是否存在其他未知的攻击痕迹与安全隐患。
九、LiteLLM 事务启迪
LiteLLM 供给链投毒事务,不仅是一次单一的安全变乱,在这次事务中我们要汲取的是三层认知升级:
开源依赖不是代码,而是组织治理
好多团队仍将依赖安全视为工程师幼我事务,但主题依赖投毒的影响已远超研发细节 —— 直接关联客户数据安全、云资源、模型预算、颁布链齐全性、合规风险及品牌融资,是 CEO/CTO/CISO/ 平台掌管人需共同面对的企业级问题。
热点开源反而是高价值攻击指标
LiteLLM 月下载量超 9500 万、单日超 340 万,重大用户基数意味着更高攻击 ROI,一旦被攻破,可实现规;缦绽┥。
Agent 时期最危险的资产是权限
好多 AI 公司聚焦模型能力、推理成本等主题竞争力,却忽视了决定企业生死的安全基建 —— 凭证治理、依赖锁定、颁布审批、权限管控、安全审计等基础环节,才是 AI 公司真正的生死线。
LiteLLM 投毒事务并非 “开源生态的黑天鹅”,而是现代软件工业 “自动化、复用化、云原生” 发展的必然了局 —— 当一行pip install能直通企业的云环境、集群、数据库和自动化系统,这行号令的背后,是企业对开源生态、颁布链路、依赖组件的层层信赖。
但信赖不蹬宗放任,开源生态的高效复用,必要 “信赖 + 验证” 的双沉安整个系作为支持,这也是KY开元多年来为企业提供数据安全服务的主题思路:
开源是数字经济与 AI 产业发展的主题动力,企业无需剖腹藏珠,但必须成立与开源生态相匹配的安全防护能力。在数据安全与开源依赖风险交错的时期,唯有将安全理想融入技术研发、基础设施建设、企业治理的每一个环节,能力在享受开源效能的同时,守住企业数据安全与业务发展的信赖底线。
附:LiteLLM 投毒事务主题速查清单
已确认受影响版本
litellm==1.82.7
litellm==1.82.8
当前公开安全版本
litellm==1.82.6
主题排查号令
沉点排查 IOC / 悠久化痕迹
可疑文件:~/.config/sysmon/sysmon.py、/tmp/pglog、/tmp/.pg_state
可疑服务:假装成 “System Telemetry Service” 的 systemd 用户服务
可疑域名:checkmarx.zone、models.litellm[.]cloud
必须全量轮换的敏感资产
SSH 密钥、
云平台凭证、
Kubernetes secrets、
.env 内所有密钥、
数据库密码、
TLS 私钥、
CI/CD tokens、
第三方 SaaS API keys
本文主题内容起源于象信AI公家号