2026 年 1 月的一个周二早上，一位安全研究员在 GitHub 上发布了一个概念验证漏洞利用代码。标题起得很低调："OpenClaw WebSocket Origin 绕过"。但影响一点都不低调。
这个漏洞利用方式简单得令人叹为观止。攻击者只需构造一个包含几行 JavaScript 的恶意网页。当 OpenClaw 用户访问这个页面——无论是点了邮件里的链接、Slack 消息里的链接，还是任何地方的链接——JavaScript 就会悄无声息地连接到用户本机运行的 OpenClaw 实例，执行任意命令。不需要认证，除了点击链接之外不需要任何用户交互，直接拿到机器的完整权限。
CVE-2026-25253 的 CVSS 评分是 8.8。安全社区定性为严重漏洞。OpenClaw 团队最初的回应是"这是 WebSocket 架构的已知限制"。这两种描述之间的落差，说明了这场危机是怎么一步步演变的。
时间线
第一个 CVE 在 1 月 14 日披露。48 小时内，Shodan 扫描发现超过 42,000 个 OpenClaw 实例直接暴露在公网——任何知道 URL 的人都可以利用。其中很多是企业部署，能访问内部文件系统、数据库，以及存在环境变量里的各种凭据。
第一个补丁还没发布，CVE-2026-26327 就来了：一个认证绕过漏洞，让攻击者可以直接跳过登录。同一周内两个严重漏洞，都可以远程利用，都影响同样那 42,000+ 个暴露实例。
然后是 ClawHub 的问题。安全研究员开始审计 OpenClaw 官方插件市场，发现 41.7% 的已发布插件存在漏洞——有些是无意的，有些是故意植入的。数百个恶意插件在过去几个月里悄悄上传，等着用户安装。XDA Developers 发了一篇文章，标题叫《请停止使用 OpenClaw》，迅速病毒式传播。
这不只是运气不好
把 OpenClaw 危机归结为一系列倒霉的 bug——就像任何项目都可能遇到的那种，打个补丁就过去了——这种想法很有吸引力，但它忽略了更深层的问题。这些漏洞不是随机出现的，它们是多年前做出的特定架构决策的可预见后果，那时候 OpenClaw 还只是个周末项目，安全不是首要考虑。
WebSocket 信任模型是第一个问题。OpenClaw 的 Web 界面接受 WebSocket 连接时不验证 Origin 头。这是一个有据可查的漏洞类型——跨站 WebSocket 劫持——自 2012 年起就广为人知。修复方法很简单：检查 Origin 头。但在 OpenClaw 里修复这个问题会破坏围绕这个宽松模型建立起来的插件生态，所以一拖再拖，最终变成了 CVE-2026-25253。
第二个问题是操作系统级别的权限。当你安装一个 OpenClaw 插件时，它以 OpenClaw 进程本身的权限运行。在大多数系统上，这意味着它可以读取你的文件、访问你的网络、执行命令，以及读取包含 API 密钥和密码的环境变量。没有沙箱，没有能力模型，没有办法只授予插件它需要的权限。你安装的每个插件都隐式地被信任可以访问一切。
第三个问题是 JavaScript 供应链。OpenClaw 的 node_modules 包含 1,200+ 个包。ClawHub 上的恶意插件正是利用了这一点——发布名称与热门包相似的包（typosquatting），等着它们作为依赖被引入。在一个有着庞大依赖树的动态语言里，这种攻击在平台层面几乎无法防范。
安全设计到底是什么样的
ZeroClaw 建立在一套不同的假设之上。不是"我们以后再加安全"，而是"安全约束从第一天起就塑造架构"。
Rust 的所有权系统在编译时消除了整类漏洞。缓冲区溢出、释放后使用、数据竞争——这些在 Rust 代码里不是需要打补丁的 bug，而是编译错误。CVE-2026-25253 之所以在 OpenClaw 里成为可能，部分原因是 JavaScript 的动态特性使得在语言层面强制执行安全边界非常困难。在 Rust 里，这些边界由编译器在代码运行之前就强制执行了。
网关配对取代了密码认证用于远程访问。ZeroClaw 不是暴露一个端口然后希望用户设置强密码，而是要求客户端和网关之间进行加密配对——类似蓝牙配对的工作方式。在公网上找到你的 ZeroClaw 实例的攻击者，没有配对密钥什么也做不了。
默认拒绝的白名单模型意味着每个工具、文件路径和网络端点都必须在智能体访问之前被明确允许。试图读取其指定工作区之外文件的插件会得到权限错误，而不是访问权限。试图向未列出端点发出网络请求的插件会被阻止。默认是无访问权限；你精确授予你需要的权限。
带有符号链接逃逸检测的工作区范围限制可以防止路径遍历攻击。即使恶意插件试图通过跟随符号链接来逃出沙箱，ZeroClaw 也会在任何数据被访问之前检测并阻止这种尝试。
单二进制架构完全消除了供应链攻击面。没有 node_modules，没有包注册表，没有需要审计的传递依赖。让数百个恶意 ClawHub 插件得以存在的攻击向量根本不存在。
迁移步骤
如果你目前在运行 OpenClaw，迁移路径很简单。首先备份你的 OpenClaw 数据——对话历史和配置在 `~/.openclaw/` 里，在动任何东西之前先备份一份。
用一条命令安装 ZeroClaw：
```bash curl -fsSL https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/main/scripts/bootstrap.sh | bash ```
先用 dry-run 模式运行迁移工具，预览会发生什么变化：
```bash zeroclaw migrate openclaw --dry-run ```
这会精确地告诉你什么会被导入、什么会被跳过、什么需要手动处理。对预览结果满意后，运行实际迁移：
```bash zeroclaw migrate openclaw ```
这会迁移你的记忆、配置和频道设置。验证你的频道是否重新连接，并用一个简单的查询测试一下。整个过程通常不到十分钟。
行业应该从中学到什么
OpenClaw 危机不是一个项目安全失败的故事，而是一个关于当基础设施软件以脚本工具的假设来构建时会发生什么的故事。
AI 智能体处理凭据、访问文件系统、执行代码，并且 24/7 运行。它们是基础设施，不是脚本。它们需要与 Web 服务器同等的安全严谨性，与数据库同等的架构纪律，以及与任何其他以提升权限在你机器上运行的东西同等的威胁建模。
安全无法被改造到一个宽松的架构上。它必须从一开始就被设计进去——在语言选择、权限模型、部署架构和插件系统中。当它没有被设计进去时，你就会得到 42,000 个暴露实例和一个 CVSS 8.8 的 CVE。
问题不是你的 AI 智能体是否会成为攻击目标，而是你的架构是否在那一刻到来时能够承受住。