NemoClaw攻击链解析：本地大模型如何被一个网页永久篡改

你随手点开一个看似普通的教程网站，几秒钟后，你电脑上运行的本地大模型可能已经被永久篡改。从这一刻起，它每次回复你之前，都会先读一段你完全看不见的隐藏指令。

这不是科幻脑洞。2025年8月25日，安全公司 Oasis Security 公开了一条完整的攻击链，攻击目标正是英伟达（NVIDIA）的开源项目 NeMo Agent Toolkit（俗称 NemoClaw），以及运行其上的本地大模型服务 Ollama。

NeMo Agent Toolkit：一个热度极高的攻击目标

NeMo Agent Toolkit 是英伟达在 2025 年 3 月开源的一套参考架构，用于让各种 AI Agent 在沙箱中安全运行。AI Agent（智能体）是当前大模型应用的核心范式之一，它不仅能对话，还能自主调用工具、读写文件、执行代码。与传统的聊天机器人不同，Agent 拥有「感知-决策-行动」的闭环能力，这意味着一旦 Agent 被劫持，攻击者获得的不仅是对话内容，还包括 Agent 被授权操作的所有资源。NeMo Agent Toolkit 正是为这类场景设计的运行框架，它提供沙箱隔离、工具注册、权限管控等能力，理论上是安全防线的一部分。

它默认集成了当下最火的开源助手 OpenClaw——这个项目曾创下 5 天涨 10 万星的记录，其作者甚至在今年 2 月被 Sam Altman 招进了 OpenAI。除了 OpenClaw，Hermes、LangChain 系的 Agent 也能在这套框架里跑。

NeMo Toolkit 本身开源不到半年，Star 数已经突破 2.2 万。但热度是一回事，安全是另一回事——这条攻击链恰恰击中了「本地部署」被普遍误认为「绝对安全」的盲区。

Ollama接口无需认证

Agent 干活靠的是「大脑」，这个大脑就是 Ollama——一个在你本机上跑大模型的服务。Ollama 是当前最流行的本地大模型运行工具之一，它将模型的下载、量化、推理、API 服务整合为一条命令即可启动的体验。其设计哲学是「像 Docker 一样管理模型」——用户可以 pull、run、create 模型，就像操作容器镜像一样。Ollama 提供的 REST API 涵盖了模型管理（/api/pull、/api/create、/api/delete）和推理服务（/api/chat、/api/generate）等全部功能。

它监听在 11434 端口，而这个接口一个密码都没有。它本来只给本机工具使用：下模型、建模型、聊天，全部无需认证。之所以默认不设认证，是因为 Ollama 假定自己只在本机回环地址（127.0.0.1）上运行，仅供同一台机器上的应用调用。这一设计在单机场景下尚可接受，但一旦监听地址被改变，认证缺失就变成了致命漏洞。

攻击原理：一个网页如何摸到你本机的模型？

正常情况下，浏览器有「同源策略」，外部网站想访问你的 localhost 会被直接拦截。同源策略（Same-Origin Policy）是浏览器安全模型的基石，它规定只有协议、域名、端口三者完全相同的请求才被视为「同源」，否则浏览器会拦截跨源请求的响应。CORS（Cross-Origin Resource Sharing）则是一种协商机制，服务端通过返回 Access-Control-Allow-Origin 等头部来声明哪些外部来源可以访问自己。

但这条攻击链通过三道防线的连环失守，绕过了所有保护。

第一环：错误的监听地址导致安全校验失效

NeMo Toolkit 在 Windows 上启动 Ollama 时，把监听地址设成了 0.0.0.0，意思是「所有网卡都在监听」。在网络编程中，0.0.0.0 是一个特殊的「通配」地址，表示服务绑定到主机上所有可用的网络接口——包括本机回环接口（127.0.0.1）、局域网接口（如 192.168.x.x）、以及任何其他物理或虚拟网卡。与之相对，绑定到 127.0.0.1 则意味着服务只接受来自本机的连接。在开发环境中，开发者常常为了方便调试而使用 0.0.0.0，但在日常使用场景中，这等于向同一网络中的所有设备敞开大门。

地址一变，规则跟着崩塌：这个配置带来了双重后果。当绑定的不是本地回环地址（127.0.0.1）时，Ollama 内部的逻辑认为这是一个「有意对外暴露」的配置，于是 Ollama 的第一道 Host 头校验直接被跳过，第二道 CORS 检查也失效——请求头里的来源和目标看起来像是同一个网站。

Ollama 内部之所以会因绑定地址不同而改变校验行为，与其代码设计逻辑直接相关。Ollama 在启动时会判断当前监听地址是否为「本地回环」（127.0.0.1 或 ::1），如果是，则认为处于受信任的本机环境，Host 头校验和 CORS 限制正常生效；一旦检测到绑定地址是 0.0.0.0 或具体的局域网 IP，代码逻辑会将其解读为「用户有意对外提供服务」，从而放宽限制——Host 头校验被跳过，CORS 响应头也变得宽松。这种「按绑定地址推断意图」的设计在2024年的 CVE-2024-28224 修复中已经暴露过问题，但修复规则本身留下的例外条件，恰好被此次 NeMo 的错误配置（强制使用 0.0.0.0）再次触发。换言之，两个独立的设计缺陷叠加在一起，才形成了这条完整的绕过路径。

第二环：DNS Rebinding绕过浏览器限制

最后一环叫 DNS Rebinding（DNS 重绑定）——这是一种巧妙利用 DNS 解析时间差来绕过同源策略的攻击技术。攻击者注册一个自己控制的域名（如 evil.example.com），最初让它解析到攻击者服务器的 IP，浏览器加载恶意页面后，攻击者将 DNS 记录改为 127.0.0.1（受害者本机），并将 DNS TTL 设得极短（通常为 0 秒）。当页面中的 JavaScript 发起后续请求时，浏览器重新解析域名，得到 127.0.0.1，但由于域名没有改变，浏览器认为这仍然是「同源」请求，于是放行。整个过程中，受害者的本机服务收到的请求看起来完全合法，Host 头是攻击者的域名而非 localhost，这就是为什么 Host 头校验在此场景中至关重要——而上一环恰恰跳过了这个校验。

关键在于：整个过程不需要你的电脑暴露在公网。发请求的浏览器就在你自己机器上，攻击从内部发起。

DNS Rebinding 之所以能持续奏效，根源在于浏览器「同源」判断依赖域名而非最终解析的 IP 地址。浏览器在同源比较时只看协议、主机名和端口三者，不会在每次发起子请求时重新验证该域名当前解析到哪个 IP。攻击者将 DNS TTL 设为 0 或极小值（如 1 秒），使 DNS 记录可以在浏览器已经加载页面之后迅速切换。部分浏览器实现了「DNS 固定（DNS Pinning）」机制来缓解这一问题，即在标签页生命周期内缓存 IP 解析结果；但这一机制并非规范强制，实现参差不齐，且可被页面长时间停留后的重新解析绕过。防御 DNS Rebinding 的最可靠手段始终在服务端：严格校验 Host 请求头，拒绝任何不在白名单内的主机名，无论请求来自何处。

核心危害：永久篡改聊天模板实现提示词注入

进了门能干什么？真正致命的操作在这里。

大模型在读取你的对话之前，有一层「聊天模板」——你可以把它理解成一张格式单，之后所有对话都要按这个格式拼好才喂进模型。聊天模板（Chat Template）是将多轮对话结构化编码为模型可理解的文本格式的关键组件。不同模型家族使用不同的模板语法——例如 Llama 系列使用 [INST]...[/INST] 标记，ChatML 格式使用 <|im_start|>system 等标签。模板定义了 system 提示词、用户消息、助手回复的拼接方式，而模型本身并不区分这些角色标记和实际内容，它只是处理一个连续的 token 序列。

攻击者调用了一个叫 create 的接口，把这张格式单换成了新版。

篡改后的模板在每次对话中注入恶意指令

新模板会在每次对话里悄悄插入一段攻击者写好的文字，注入到 System 提示词——也就是给模型「立规矩」的位置。由于 system 提示词在模型的注意力机制中通常拥有最高优先级（它是上下文窗口中最早出现的内容），被注入的指令会覆盖后续用户或 Agent 设定的规则。模型没有眼睛，它看到的世界就是模板拼出来的结果。改了模板，等于改了它看到的整个世界。

更可怕的是，这个改动是永久的：聊天模板存储在模型的 Modelfile 中，属于模型元数据的一部分，普通用户在对话界面上完全看不到这一层，也没有标准化的工具来检测模板是否被篡改。新开对话没用，Agent 自己写的提示词也盖不掉它。Oasis 研究方有一句原话——「客户端根本看不见这个模板，想检测无从谈起」。

这意味着你的本地 AI 从此自带后门：它能看到你所有的对话，还能借 Agent 的手去访问你的文件和工具。正如报告所言：「沙箱保护的是端点，可一旦接管了 Agent，就接管了它全部的权限。」

修复现状：Windows版Ollama至今未修补

先说好消息：目前尚未发现真实攻击案例，也没有分配 CVE 编号。

漏洞尚未分配CVE编号

坏消息是：macOS 和 Linux 已在 v0.0.35 版本修复，但 Windows 这条路到今天仍未修复。更棘手的是，本应挡住这次攻击的那道校验，在 WSL 路径上根本不运行。WSL（Windows Subsystem for Linux）是微软提供的在 Windows 上运行 Linux 环境的兼容层。WSL 2 使用了一个真正的 Linux 内核运行在轻量级虚拟机中，拥有独立的网络栈和 IP 地址。当 Ollama 通过 WSL 路径运行时，WSL 环境中的网络配置与 Windows 宿主机存在映射关系，某些在 Windows 原生环境中会执行的安全校验，在 WSL 的网络转发路径上可能根本不会被触发——请求的来源地址和网络接口信息可能与预期不同，导致安全逻辑被绕过。

值得警惕的是，这套手法并非首次出现。早在 2024 年 3 月，Ollama 就修过一个几乎相同的 DNS Rebinding 入口（CVE-2024-28224），安全公司 NCC Group 随后发布过公告。当时的修法是校验 Host 头，但规则留了口子：绑定的不是本机地址时，校验自动关闭——而 0.0.0.0 正是这种地址。

今年 2 月，OpenClaw 也被类似的浏览器手法劫持过，官方 24 小时内发布修复；其技能市场此前还扫出过 1000 多个恶意技能包。本月初，同样的模板投毒手法刚在另一个叫 Paperclip 的 Agent 上演示过一遍。老补丁配新组合，这类攻击大概率还会卷土重来。

WSL 2 的网络架构是理解为何安全校验在该路径失效的关键。WSL 2 在 Hyper-V 轻量虚拟机中运行一个完整的 Linux 内核，拥有独立的虚拟网络接口（eth0）和私有 IP 段（通常为 172.x.x.x）。Windows 宿主机与 WSL 2 之间通过一个虚拟交换机互联，WSL 内部发出的网络请求在到达 Windows 宿主机时，来源地址已经是 WSL 的虚拟 IP 而非 127.0.0.1。当 Ollama 运行在此路径下时，即便其监听地址名义上是 127.0.0.1，经过 WSL→Windows 的端口转发，请求的实际来源地址已发生变化，导致 Ollama 内部以 IP 为依据的本地判断逻辑产生误判，安全校验路径被跳过。这一问题需要在 WSL 网络层或 Ollama 自身逻辑中专门处理，而不是简单复用 Linux 原生路径的修复方案。

防护指南：运行本地模型必做的四件事

NeMo后端绑定地址错误时拒绝启动

针对这条攻击链，有几项防护措施值得立即执行：

1. 升级NeMo和Ollama到最新版本

从 v0.0.106 起，NeMo 后端在发现绑定到错误地址时会直接报错拒绝启动。同时，那个能跳过检查的环境变量千万不要碰。

2. 将Ollama绑定到127.0.0.1

Ollama 只绑 127.0.0.1。绑 0.0.0.0 等于把门全部敞开——除非你非常清楚自己在做什么。这一点至关重要：即使你的电脑在路由器或防火墙后面，DNS Rebinding 攻击也能通过浏览器从内部发起，绕过所有网络层面的防护。

3. 加一层反向代理认证

讲究一点的做法是在前面套一层反向代理（如 Nginx 或 Caddy），加上认证（如 Basic Auth 或 Token 校验），顺手把 Host 头校验打开。这正是 2024 年那份 NCC 公告给出的方案。反向代理还能提供请求日志和速率限制，为后续的安全审计提供数据支撑。

4. 定期检查聊天模板完整性

养成习惯，隔段时间看看聊天模板有没有被改动。可以通过 ollama show <模型名> --modelfile 命令查看当前模型的 Modelfile 内容，比对其中的 TEMPLATE 和 SYSTEM 字段是否与预期一致。披露前有媒体逐行合过代码，整个仓库找不到一处完整性检查——它的程序去查接口时只关心模型支持多长上下文，对模板本身毫无防护。

写在最后：本地部署 ≠ 安全边界

浏览器这边没有补丁可打，只能靠配置习惯兜底。这也是这次事件最想让人记住的一句话：

本地部署不等于私人领地，localhost 也不是安全边界。

你在本机跑的不只是一个模型文件，还有模板、还有配置。这些看不见的东西，本该有人盯着。当我们把越来越多的 AI Agent 放在本机运行、赋予它们访问文件和工具的权限时，「本地」二字带来的安全错觉，反而可能成为最大的攻击面。这次事件再次印证了安全领域的一个经典原则：信任边界（Trust Boundary）必须被显式定义和强制执行，而不能依赖于网络拓扑或部署位置的隐含假设。