OpenClaw 安全风险：本地模型解决方案

OpenClaw 正处于安全危机之中，而大部分报道关注的是错误的问题。

是的，CVE-2026-25253 很严重——一个 CVSS 评分 8.8 的一键远程代码执行链。是的，ClawHub 供应链攻击令人震惊——发现了超过 800 个恶意技能，约占整个注册表的 20%。是的，30,000+ 个在互联网上暴露且未经身份验证的实例是很糟糕的。

但这些都是症状。根本的漏洞是架构层面的：OpenClaw 被设计用来读取你的文件、访问你的邮件、浏览网页和执行 shell 命令——而默认情况下，它通过云 API 发送所有上下文来执行这些操作。

这才是没有人在修补的攻击面。

数据流问题

当 OpenClaw 使用云 API 后端（默认配置）运行时，每次交互都会发生以下情况：

**你让 OpenClaw 总结你的邮件。**你的邮件内容作为提示词上下文发送到 OpenAI/Anthropic 的服务器。
**你让它审查合同。**完整的合同文本被传输到第三方 API。
**你让它检查服务器日志。**你的基础设施详情、IP 地址和错误信息离开了你的网络。
**你让它起草客户提案。**你的定价、策略和客户详情成为 API 输入。

OpenClaw 读取的每个文件、处理的每个命令输出、渲染的每个浏览器页面，都作为 token 输入流过云端点。这就是预期的架构。

CrowdStrike 的分析说得很清楚：OpenClaw 的广泛权限，加上云 API 路由，创造了一个场景——"如果员工在企业机器上部署 OpenClaw 并将其连接到企业系统，同时配置不当且不安全，它可能成为一个强大的 AI 后门 Agent。"

Meta 禁止 OpenClaw 进入其企业网络。Cisco 的博客称像 OpenClaw 这样的个人 AI Agent 是"安全噩梦"。Kaspersky 将该工具标记为不安全。这些都不是过度反应。

为什么修补 CVE 远远不够

安全社区关注三个攻击向量：

**1. RCE 漏洞（CVE-2026-25253）。**这个会被修补。但下一个 RCE 终究会到来——OpenClaw 的攻击面在设计上就是巨大的。一个能执行任意 shell 命令、管理文件和控制浏览器的 Agent 永远是高价值目标。

**2. 恶意 ClawHub 技能。**800+ 个中毒技能（投递 Atomic macOS Stealer）暴露了社区技能注册表的根本问题。大规模审查开源扩展是一个未解决的问题。

**3. 暴露的实例。**30,000+ 个面向互联网的 OpenClaw 部署是配置问题。端口加固和身份验证会减少这个数字，但人为错误保证总会有一些实例被暴露。

这些修复都没有解决核心问题：即使是一个完美安全的 OpenClaw 实例，默认情况下仍然将你的数据发送到云 API。

本地模型：消除最大的攻击面

在本地模型上运行 OpenClaw 完全消除了数据外泄向量：

风险	云 API	本地模型
数据发送给第三方	每个提示词、每个文件、每个上下文	没有——推理在你的硬件上运行
API 密钥暴露	密钥存储在配置中，在日志中泄露，通过提示词注入被窃取	没有 API 密钥可泄露
厂商数据留存	受制于提供商的数据处理政策	你控制留存
网络拦截	传输中的 token 到 API 端点	推理无网络流量
提示词注入 → 数据窃取	攻击者构造的提示词可通过 API 调用外泄上下文	没有外部端点可供外泄

这消除了整类攻击。

提示词注入变得不那么危险

OpenClaw 被引用最多的风险之一是提示词注入：恶意网站、邮件或文档可能包含隐藏指令来欺骗 OpenClaw 执行有害操作。使用云 API 后端，成功的提示词注入可以通过将数据编码到 API 调用中来外泄数据。使用本地模型，没有外部端点供注入的提示词回传。

提示词注入在使用本地模型时仍然是一个风险——注入的指令仍然可能触发有害的本地操作。但数据外泄向量消失了。

API 密钥不再是目标

OpenClaw 的默认设置要求在配置文件中存储 API 密钥。这些密钥已被发现在明文日志中、通过不安全实例暴露、通过提示词注入攻击被窃取。当你运行本地模型时，没有 API 密钥可被窃取。大多数 OpenClaw 部署中最有价值的凭据根本不存在。

模型质量如何？

常见反对意见："本地模型不如 GPT-4。"对于通用任务来说这是对的。而领域专属的 Agent 工作则正好相反。

OpenClaw 重复执行的任务——邮件分类、文档摘要、数据提取、报告生成——正是微调小模型匹配或超越前沿模型的任务：

B2B 任务分类：微调 7B 94% 准确率 vs 提示词工程 GPT-4 的 71%
支持工单解决：微调模型 87% 自动解决率 vs RAG 增强聊天机器人的 34%
法律条款标注：微调模型在领域特定合同上达到 90% 准确率

对于构成 OpenClaw 使用 80%+ 的狭窄、可重复任务，微调本地模型就是升级。

OpenClaw 的实用安全架构

以下是如何以可防御的安全姿态部署 OpenClaw：

1. 本地模型作为主要后端

通过 Ollama 在与 OpenClaw 相同的机器或本地网络上部署微调模型。所有常规任务通过此模型路由。没有数据离开你的基础设施。

{
  "models": {
    "providers": [
      {
        "name": "local-secure",
        "api": "openai-completions",
        "baseUrl": "http://127.0.0.1:11434/v1",
        "models": ["my-finetuned-model"]
      }
    ]
  }
}

2. 带数据过滤的云端回退（可选）

如果你需要云 API 访问处理边缘情况，仅将非敏感查询路由到云端后端。永远不要通过云 API 发送文档、邮件或专有数据。

3. 禁用或审计 ClawHub 技能

不要在不审查源代码的情况下从 ClawHub 安装社区技能。改为构建由你的微调模型支持的自定义技能——这完全避免了供应链风险。

4. 网络隔离

在除受控渠道外无法访问互联网的机器上运行 OpenClaw。本地模型推理不需要任何出站网络访问。

5. 针对安全意识进行微调

在你的微调数据集中包含安全相关的训练样本：

提示词注入尝试的正确拒绝响应示例
在执行前应触发确认的模式（文件删除、系统命令、凭据访问）
关于模型应该和不应该处理的数据类型的边界执行

企业场景

对于评估 OpenClaw 内部使用的组织，安全计算很简单：

使用云 API：每次交互都将内部数据传输到第三方基础设施。每个 API 密钥都是高价值目标。OpenClaw 中的每个漏洞都是潜在的数据泄露向量。
使用本地模型：推理与外部服务隔离。没有凭据可窃取。任何漏洞的影响范围仅限于本地机器。

Meta、Cisco 和 CrowdStrike 的安全团队标记 OpenClaw 风险是正确的。解决方案是消除使其危险的数据流。

运行你自己的模型。保持数据在本地。这是 CVE 补丁永远无法提供的修复。