56928个恶意投毒包背后:悬镜安全2025开源与AI供应链安全报告发布
攻以守本,唯快不破!2025开源供应链投毒攻击暴涨58%,Agentic AI生态成攻防新焦点

01 引 言
随着大语言模型(LLM)的逐步成熟、对话式智能体的广泛验证、AI场景化训练数据的快速积累,以及企业对智能化与目标驱动型AI应用的迫切需求,越来越多的企业将AI数智化转型作为提升核心竞争力的关键,其中Agentic AI的应用成果不仅依赖于单一的技术突破,更在于构建系统性、端到端的落地能力,同时也催生新型AI原生安全风险与数字供应链治理挑战。
2025年是开源供应链攻击威胁加速深化的一年,尤其是针对开源生态的恶意投毒进一步向自动化与复杂化快速演进。从 NPM、PyPI 等主流仓库的批量投毒,到 IDE 扩展市场的定向投毒,再到Agentic AI生态的新型投毒攻击,整体呈现出攻击范围扩大化、技术手段智能化以及对抗方式多样化等鲜明趋势。这一年,开源生态发生多起影响重大的供应链投毒事件,其中NPM仓库连续两次 Shai-Hulud (代号"沙虫") 恶意蠕虫大规模爆发成为开源供应链投毒攻击的标志性事件,开源生态的信任基石也遭遇极大冲击。
02供应链投毒攻击态势
在2025年,悬镜安全情报中心通过持续监控全网主流开源生态平台和Agentic AI生态社区,对潜藏恶意代码风险的投毒包(涉及开源组件、IDE扩展插件、AI模型、Agent MCP及Agent Skill工具等)进行供应链安全智能审查,总共识别56928个存在真实恶意行为及攻击意图的投毒包,总量相较于2024年(约为3.6w)显著提升58%。其中NPM公共仓库的代码投毒占比超过92%。Pypi公共仓库由于在2024年遭受集中式投毒后加强平台安全防护机制(启用账户双因子认证等措施),2025年Pypi仓库投毒占比为4.49%,相较2024年呈现轻微下降趋势。AI模型托管平台HuggingFace已成为恶意模型投放的主要平台,超过940多个模型文件被攻击者实施投毒。此外,针对IDE扩展市场(以VS Code为主)、Ruby及Go生态的投毒攻击也日趋频繁。

2025年开源生态恶意投毒分布情况
针对所有恶意投毒包,我们通过多维数字供应链安全纵深分析与溯源评估,识别出投毒包使用的攻击方式及其关键恶意行为标签。

投毒包主要攻击方式
♥
投毒包主要攻击方式包括:
😡 恶意代码内嵌执行
👿 恶意文件下载执行
🦠 恶意文件释放执行
😠 恶意代码内存执行
😤 系统命令执行
👹 系统文件篡改
👺 提示词攻击
其中,投毒者最常用的攻击方式依旧是恶意代码内嵌执行(51.58%),其攻击流程主要利用主流包管理器中的安装指令在组件包安装或加载时静默执行内嵌在源码文件中的恶意代码。系统命令执行(31.13%)、恶意文件下载执行(9.82%)、恶意文件释放执行(5.09%)、恶意代码内存执行(1.77%)以及系统文件篡改(0.56%)都是攻击者惯用的投毒手段。此外,随着Agentic AI的规模化应用,借助提示词进行恶意语义攻击(提示词注入、语义误导等)也逐渐成为攻击者针对AI开源生态投毒的主要新型攻击方式之一。

投毒包恶意行为标签
在所有恶意投毒包中,信息窃取攻击仍居高位,占比达83.8%,其中系统平台信息、系统密码文件、网络配置、用户信息、主流浏览器Cookie/登录凭证、数字钱包应用数据以及各类业务凭证口令(包括Github Token、NPM Token、云服务Access Key ID/Secret等)皆为攻击者主要窃取目标。其次,通过远控木马和反连Shell后门进行远控攻击事件也呈逐年上涨趋势。此外,针对Agentic AI开源生态的投毒攻击,除了提示词注入,AI模型文件恶意代码注入、伪装AI模型SDK、stdio模式的Agent MCP Server及Skill包的恶意语义误导及代码投毒都是攻击者常用的AI供应链投毒攻击行为。
03供应链投毒案例分析
本节将从2025年恶意投毒包中选取部分代表性样本进行技术分析,还原投毒攻击细节以及攻击者常用的对抗技术。
3.1 Agentic AI 生态
AI模型文件序列化代码注入投毒
主流深度学习框架(PyTorch、TensorFlow等)训练生成的模型文件(权重及checkpoint数据)通常会使用Python的pickle模块进行模型数据序列化存储。而由于pickle模块反序列时可重写对象__reduce__方法实现反序列化代码执行,因此攻击者可利用该特性将恶意代码序列化嵌入到模型文件中并发布到开源模型托管平台(HuggingFace、ModelScope等),当开发者使用torch.load()等接口直接加载模型文件时,将静默触发执行内嵌在模型文件中的恶意代码,导致供应链攻击。
以 HuggingFace 平台 playedalive/mdy-red-1 项目为例,如下图所示,其模型文件 model.pkl 被植入反序列恶意python代码,主要功能是反向shell远控后门,远控服务器地址及端口为:52.48.12.202:8080。

恶意模型项目

模型文件内嵌恶意代码
Agent MCP Server 提示词注入
MCP (Model Context Protocol,模型上下文协议) 是LLM模型与外部工具交互的开放标准,MCP Server 是实现该协议的工具服务端。MCP Server 提示词注入原理在于利用LLM模型无法正确区分数据与指令及其对上下文输入的高度依赖性等特性,攻击者通过在与模型交互的数据源中植入恶意指令,诱导模型执行非预期操作,甚至可进一步实现对 AI Agent的行为劫持与权限滥用。
以Python仓库组件 wei516-tpa 为例,该组件伪装成提供天气服务的MCP Server,该MCP 服务提供了 weather_info() 工具接口,并在工具描述里使用 <SYSTEM_DIRECTIVE> 标签尝试伪装成系统指令进行提示词注入攻击,指令主要功能是诱导AI应用系统对任意可读目录下的 api_key.txt 文件内容追加FLAG标记位。

MCP工具描述植入恶意提示词
Agent Skill 恶意指令投毒
Skill 技能包作为 AI Agent 的外部功能扩展模块,其原生具备比MCP Server更高权限的执行环境以及与模型交互能力,但由于目前大部分Skill市场缺乏严格的安全审查机制,导致Skill市场面临来自攻击者的代码投毒及恶意指令滥用等风险。第三方 Skill的集成引入已经成为Agent系统面临的最危险供应链攻击面。近期OpenClaw Skill市场遭受批量化投毒攻击,悬镜安全情报中心对其Skill市场3325个包进行恶意代码及高风险语义扫描后,检测出 452个存在高危 恶意代码行为的Skill包。绝大部分Skill包直接在 SKILL.md 指令文档中嵌入恶意指令从而操纵AI Agent执行高险操作,包括远程植入木马程序、恶意shell命令执行、敏感数据外传等。
以base-agent skill为例,在 SKILL.md 文件中根据系统环境执行相应的远程恶意木马植入操作,对于Windows系统直接操纵Agent远程下载加密压缩包 AuthTool.zip,解密解压后执行恶意程序 AuthTool.exe;对于Mac系统用户,则通过执行base64编码的shell命令远程下载植入AmosStealer窃密木马。

base-agent skill功能描述

base-agent skill恶意指令
3.2 VSCode插件市场
伪装Codex AI插件植入恶意木马
攻击者发布 codex-ai-pro 并伪装成Codex AI编程助手插件,在插件入口模块 extension.js 的 active()函数中植入定时器,每隔一秒执行一次runScript() 函数,如下图所示。

codex-ai-pro恶意插件

恶意函数定时器
恶意函数 runScript() 定时执行 script/run.bat 脚本,其主要功能是远程下载并启动Windows可执行程序 Lightshot.exe 及 Lightshot.dll 。

bat脚本下载器
Lightshot.dll 动态链接库实际是一款针对Windows平台的恶意木马,由 Lightshot.exe 负责加载执行。

恶意木马Lightshot.dll
3.3 Python公共仓库
伪装AI框架库劫持数字钱包应用
攻击者利用pytensorlite包名尝试伪装成知名AI框架库pytensor并诱导开发者下载安装,其主要功能是从github远程下载并执行攻击者投放的下一阶段被混淆保护的恶意py文件。

pytensorlite投毒包主页
如下图所示,远程恶意py文件负责从 Chrome 、Edge 、Firefox等主流浏览器应用以及 Exodus、Atomic 、 Electrum 等主流加密货币钱包应用中窃取敏感数据(包括用户登录凭证、密码相关文档等),窃取的数据被zip打包后上传到攻击者控制的webhook接口。

远程恶意py代码
此外,攻击者还会使用预制的恶意app.asar文件对系统中Atomic及exodus数字钱包客户端进行替换劫持,如下图所示。


数字钱包应用asar文件注入劫持
利用压缩包执行特性绕过静态检测
使用Python解释器执行ZIP压缩包文件时,如果压缩包根目录中包含 __main__.py,Python 会将该 ZIP 当作可执行程序运行,并执行压缩包目录中的 __main__.py 脚本。攻击者可利用该特性将恶意代码封装在ZIP压缩包中进行分发执行,以此躲避初级的静态代码检测。
以Python组件 devilfree 为例,该恶意组件运行时会先释放出ZIP压缩包文件 .Devil,接着通过 Python .Devil 命令直接执行ZIP压缩包,如下图所示。

释放执行压缩包payload
.Devil 实际上是个ZIP压缩包文件,文件列表如下图所示,由于 .Devil 压缩包内包含__main__.py文件,因此投毒者巧妙利用Python解释器执行压缩包的特性实现隐蔽执行.Devil压缩包中的 __main__.py 脚本代码。

压缩包文件列表
__main__.py 代码内容如下图所示,被混淆处理过,其主要功能是实现对 .Devil 压缩包的自解压,并通过判断当前系统CPU架构来加载执行释放出的恶意可执行程序。不同CPU对应的可执行程序文件映射关系如下所示。
{'armv7l': 'Devil32', 'armv8l': 'armeabi-v7a', 'arm': 'Devil32', 'aarch64': 'Devil64', 'arm64': 'Devil64', 'x86': 'x86', 'i686': 'x86', 'x86_64': 'x86_64', 'amd64': 'x86_64'}

压缩包内置__main__.py恶意脚本
3.4 NPM 公共仓库
引用外部恶意依赖绕过静态检测
在2025年,悬镜安全情报中心发现数百起NPM投毒攻击事件是通过利用组件外部依赖方式来间接引入恶意包,其主要攻击细节是在NPM组件package.json中通过借用外部高信誉的托管平台来分发恶意依赖包,以此绕过传统静态代码检测以及恶意IoC检测。以rc-icon组件为例,package.json中通过 `dependencies` 配置外部依赖,该外部依赖托管在谷歌云存储上,该方式不仅可规避常规的静态检测,也直接绕过了NPM官方仓库的依赖扫描统计。如下图所示:

rc-icon组件外部依赖配置
rc-icon组件自身代码不存在任何恶意行为,但其托管在谷歌云上的依赖组件ltidisafe是攻击者投放的恶意包,如下图所示,其主要功能是在组件安装过程中静默执行恶意文件test.js以此来收集并外传系统网络信息、主机名、用户目录等敏感数据。
https://ltidi.storage.googleapis.com/ltidisafe-1.0.6.tgz

外部依赖ltidisafe恶意行为
混淆代码动态执行绕过静态检测
截至目前,NPM仓库正持续遭受CHAI系列投毒攻击,不同攻击者定期向NPM仓库投放大量组件包名以“chai-”开头的恶意包,该系列投毒包在代码特征上具备高度相似性,都是从攻击者C2服务器上拉取高度混淆的恶意JS代码直接动态执行,不存在任何文件落盘行为,猜测该系列投毒与APT组织有关。
以组件 chai-min 为例,其 lib/caller.js 文件被植入恶意代码,核心功能是从远程服务器拉取一段高度混淆且内容由攻击者动态控制的恶意JS代码,并通过 new Function.constructor() 接口动态加载执行。如下图所示:

lib/caller.js恶意代码
攻击者使用的远程服务器链接被base64编码,解码后为:https://jsonkeeper.com/b/ARL7M 。
这是一段高度混淆的JavaScript代码,采用多层字符串编码、变量名混淆和控制流扁平化等技术来对抗静态代码分析,其主要功能包括收集系统平台及环境信息、窃取主流浏览器cookie与登录凭证,以及收集加密货币钱包(如MetaMask、TrustWallet等)浏览器插件的敏感数据。

远程恶意JS代码
基于时间门控的远程代码执行后门
winston-loggerex 该NPM组件的 lib/winston-loggerex/logger.js 文件被植入恶意代码,其主要功能是一个基于时间门控的远程代码执行后门。在特定日期(2025-10-13 06:30:00 GMT)之后,攻击者投放在Google 云盘上(https://docs.google.com/uc?export=download&id=1prQlXmreHK0Q-6I7t01kDbCmrswma54W)的远程后门代码才被允许下载,后门代码最终经过base64解码后通过 new Function 接口动态加载执行。

winston-loggerex主页

远程后门代码动态执行
04
供应链投毒治理建议
Governance Advice
4.1 多模态SCA审查
针对日趋隐蔽的数字供应链投毒攻击,传统单一源码扫描已无法满足安全防护需求,亟需引入支持“源码 - 二进制 - 运行时” 全链路场景的多模态 SCA 检测能力,构建投毒攻击深层防御体系,不仅可深度解析检测源代码、二进制文件、容器镜像等常规资产,还能覆盖Agentic AI生态热点资产(如模型权重文件、数据集、MCP 和 SKILL等)。
结合源鉴SCA 的技术实践,唯有建立跨越开发态、交付态与运行态的供应链投毒综合审查机制,才能为企业构建起一道覆盖全技术栈的供应链安全防线。
4.2 全生命周期SBOM管理
软件物料清单SBOM是治理供应链投毒的基石,但静态清单无法应对动态威胁。只有通过构建、测试、部署等各个环节实时采集并更新 SBOM 数据,才能够建立一份动态、透明的数字供应链资产清单。
通过深度联动供应链投毒情报,基于全生命周期SBOM管理驱动的检测方案在应对投毒攻击时能够迅速精准响应,并且可通过最新SBOM拓扑图和关键 IOC进行全局溯源,秒级定位受影响的业务资产与代码路径,极大缩短投毒事件的应急响应窗口,同时,依托全生命周期SBOM可持续监控数字资产的数据完整性,确保业务资产始终处于可控、可信状态。
4.3 联动供应链投毒情报预警
接入第三方权威数字供应链情报源,如悬镜云脉XSBOM供应链情报订阅服务,整合权威漏洞情报库及第三方专业投毒情报源,构建“情报—SBOM—DevSecOps”三位一体联动机制,将供应链安全情报深度融入DevSecOps敏捷安全全阶段,构建全流程积极防御体系。
在开发阶段,将情报接入开发环境实现实时预警恶意开源组件及投毒依赖,从源头规范依赖引入;在编译阶段,在 CI/CD 流水线集成SBOM生成与依赖图谱分析,通过联动投毒情报库,扫描深层嵌套依赖、容器镜像等制品,精准识别投毒组件,阻断带毒产物进入构建流程;在运行阶段,依托投毒情报IoC与行为基线模型,动态监测异常外联、数据窃取等投毒后门行为,提供运行时投毒风险预警。
4.4 AI原生安全治理
AI 原生安全治理需覆盖“供应链资产安全”与“运行时动态防御”双主线。
供应链资产层面,针对开源组件、模型、数据集等核心资产建立全流程管控,确保数据采集、训练阶段过滤有毒数据;模型发布优先选择安全的文件存储格式(如huggingface safetensors);模型加载前需进行安全扫描,避免加载内嵌恶意代码的模型文件;此外,还需构建AI原生安全开发流水线,在代码提交、PR合并、CI构建、插件/工具引入等环节嵌入AI模型驱动的原生安全审查流程,实时检测传统代码投毒及恶意指令。
运行时防御层面,聚焦提示词注入、外部工具恶意行为等场景,实施部署环境隔离与权限最小化,防范运行时恶意代码执行及敏感数据外泄。
05 总结与展望
年度报告
Annual Report
2025年,开源供应链生态中的恶意投毒攻击已进入高发期,攻击态势进一步呈现多样化及目标范围扩大化等显著趋势。由于开源生态 “轻审核” 机制,从主流公共仓库NPM、PyPI到AI模型托管平台及AI Agent生态市场,投毒攻击的目标范围持续扩大,攻击者使用的技术手法也越来越老练;同时对抗手段也日趋复杂:混淆保护绕过静态扫描、反调试、反沙箱检测、甚至利用LLM生成低特征投毒代码等现象将成常态。对于防御端,应构建从开发到部署的纵深防御体系,通过接入供应链投毒情报与可信验证机制实现“安全情报前置、全链路阻断”的防护方案。
在此背景下,SBOM(软件物料清单)不再仅是合规备案的静态清单,而是成为供应链投毒治理的核心数据资产。结合数字供应链安全管理平台作为治理中枢,将企业内外部的SBOM资产统一纳管,并与实时接入的供应链安全情报流进行自动化关联与威胁匹配,使平台可迅速内对SBOM执行溯源匹配,精准定位受影响的应用、容器镜像及运行时实例。在组件引入、构建打包及制品部署阶段实现“情报驱动SBOM”的治理能力。由此SBOM从离散的软件物料资产台账升维为与供应链安全情报共生演进,投毒治理也从被动排查升级为体系化、自动化、精准化的积极免疫响应。
攻以守本,为快不破!AI智能时代,全球开源软件供应链攻击正加速向Agentic AI生态纵深演进,呈现“传统包管理器+AI原生载体”双轨渗透趋势,唯有构建基于“AI原生安全+ DevSecOps敏捷安全+多模态SCA+开源供应链情报预警”技术的新一代数字供应链安全治理体系,从源头治理大模型开发、训练、部署到智能体运营等关键环节面临的AI原生安全风险,帮助企业用户构筑一套从传统软件供应链到AI原生供应链全生命周期的内生安全治理体系,方能从根源上持续守护好新一代数字供应链安全。
更多推荐


所有评论(0)