夜雨聆风
OpenClaw 安全风险拆解:源码审计、CVE 漏洞与加固方案
最近 OpenClaw 实在太火了，小编本来也摩拳擦掌准备上手实操一把。但在真正跑起来之前，总觉得安全这一关不能糊弄过去——毕竟这东西跑在你的机器上，有完整的文件系统访问、命令执行、浏览器控制权限，万一出事，后果可不是开玩笑的：
可能发生什么？
🔑 API Key 泄露 — 明文存储的密钥被恶意软件直接读走，你的平台账单直接炸裂
💰 加密资产被盗 — 如果你机器上有私钥或钱包配置，恶意 Skill 可以直接窃取
🖥️ 远程代码执行 — 点一个链接，攻击者就能在你机器上执行任意命令（这不是假设，是已披露的 CVE）
📧 身份冒充 — 你的 agent 身份配置（SOUL.md、设备私钥）被窃取后，攻击者可以”变成你”
于是，小编决定先做一轮深度调研：翻了 OpenClaw 的 GitHub 源码、跟踪了所有已知 CVE、读了 Kaspersky / Microsoft / Aikido Security 等安全厂商的审计报告，还查了 arXiv 上最新的学术分析论文。下面就把核心发现整理出来，帮大家在上手之前心里有个数。
─── 源码级安全架构分析 ───
沙箱隔离：可选且默认关闭
这可能是 OpenClaw 让人震惊的设计决策：沙箱默认关闭（sandbox.mode: "off"）。也就是说，开箱即用的 OpenClaw 实例中，AI agent 以你登录用户的完整权限运行——它能访问你的整个文件系统、执行任意 shell 命令。
✦ 三种沙箱模式
off（默认）：完全不隔离，agent 拥有与运行用户相同的权限
non-main：仅对群组/频道会话启用 Docker 隔离，你和 bot 的私聊仍在宿主机运行
all（推荐）：所有会话都在 Docker 容器中隔离运行
即使开启沙箱，还有一个关键的”逃逸出口”：标记为 elevated 的工具始终在宿主机执行。如果攻击者能通过提示词注入让 agent 调用 elevated 工具，沙箱形同虚设。
凭证存储：明文 JSON 是最大隐患
多家安全研究机构确认：OpenClaw 将 API 密钥、OAuth token 等敏感信息以明文 JSON 存储在本地文件中。这些文件路径已被恶意软件盯上：
# 以下路径均可能包含明文凭证~/.openclaw/openclaw.json # Gateway token~/.openclaw/agents/*/auth-profiles.json # API Key~/.openclaw/credentials/ # WhatsApp 等凭证~/.openclaw/.env # 环境变量~/.openclaw/device.json # Ed25519 私钥
虽然 OpenClaw 提供了 SecretRef 系统（支持引用环境变量、外部密钥管理器），但这些都是可选增强而非默认行为。
工具权限：三层体系但存在 Bug
OpenClaw 的权限控制设计了三个独立层：Agent 级白名单/黑名单、沙箱工具过滤器、Exec 审批系统。任一层拒绝即最终拒绝，这个思路是对的。但实际执行中存在多个已知 Bug：
✦ 审批系统已知问题
Issue #2402：审批完成前命令已执行
exec 工具在等待审批时就返回结果——等于审批形同虚设
Issue #26739：频道中安全配置失效
Discord/Telegram 中设置
security=full, ask=off不被正确识别Issue #12202：不支持文件路径白名单
无法限制 agent 只能访问特定目录——它要么能访问所有文件，要么用 prompt 级限制（不同模型遵守度差异巨大）
─── 重大安全事件 ───
ClawHub 恶意 Skill：约 20% 含恶意代码
ClawHub 是 OpenClaw 的技能市场，类似 npm 之于 Node.js。但安全研究者 Paul McCarty 浏览 ClawHub 仅 2 分钟 就发现了恶意软件。后续多家安全团队的审计结果触目惊心：
✦ 各方审计发现
🔍 Koi Security
审计 2,857 个 skill，发现 341 个恶意 skill（约 12%），投放 Atomic macOS Stealer (AMOS)
🔍 Snyk
扫描近 4,000 个 skill，发现 283 个包含凭证泄露缺陷（约 7%）
🔍 Cisco AI 安全团队
排名第一的 skill 被发现 9 个安全问题（2 关键 + 5 高危），通过隐藏 curl 命令外泄数据
更危险的是，恶意 Skill 安装时会向 SOUL.md（agent 的行为准则文件）写入隐蔽指令。即使你后来卸载了这个 skill，注入的恶意内容依然存活。甚至有攻击者通过定时任务（cron）定期覆盖 SOUL.md——手动修复了也会被恢复。把每一个 skill 安装当做安装可执行文件来审查。
─── 安全与工具权限 ───
MCP 协议：不强制认证
MCP（Model Context Protocol）是 OpenClaw 与外部工具通信的协议桥梁。OpenClaw 的 MCP 服务器支持 OAuth2 认证，Docker 容器以 read_only 模式运行并带 no-new-privileges 安全选项，看起来不错。
但关键问题是：MCP 协议本身不强制认证——认证完全依赖实现方。也就是说，每个 MCP server 的安全性取决于开发者的安全意识。如果你连接了一个不做认证的第三方 MCP server，你的 agent 就在一个没有门的房间里裸奔。
Exec 审批的安全细节（源码层面）
从源码来看，审批系统的设计思路其实不错：
✦ 审批系统安全设计
上下文绑定
已批准的执行绑定完整上下文（cwd、argv、env、可执行路径），文件变化则拒绝运行
防注入
sanitizeSystemRunParamsForForwarding()函数移除用户可能注入的approved字段一次性审批
使用
consumeAllowOnce()确保不能重放，120 秒超时视为拒绝Safe Bins
默认安全二进制列表（jq、cut、head 等）仅允许 stdin 输入，拒绝文件路径参数和变量扩展
注意 --dangerously-skip-permissions 这个选项——OpenClaw 的 coding-agent 集成 Claude Code 时支持此模式，它绕过整个安全栈（命令黑名单、写入限制、权限提示），且所有子代理继承完整自主权限。千万别用。
─── 网络安全与消息入口分析 ───
消息平台：每个集成都是一扇门
OpenClaw 支持 50+ 消息平台集成，每一个都是潜在的攻击入口。统一的访问控制模型包含 DM 策略、白名单、群组策略和 @mention 要求，但各平台风险各异，例如：
✦ 各平台安全注意点
iMessage（最高风险）
需要 macOS Full Disk Access 权限读取消息数据库，使用个人 Apple ID 会导致消息同步到 iCloud。必须使用独立 Apple ID + 独立 macOS 用户。
Discord / Telegram
确保
dmPolicy: "pairing"（配对模式），群组中启用requireMention: true，限制只有你的消息它才回应。使用非官方 Baileys 库，违反服务条款，存在封号风险。
提示词注入：架构性不可解问题
OpenClaw 官方文档自己也承认：“There is no ‘perfectly secure’ setup.” 提示词注入是 AI agent 的架构性难题——指令和数据共享同一个 token 流，模型无法 100% 区分”用户想让我做什么”和”数据里藏着什么指令”。
arXiv 论文《Don’t Let the Claw Grip Your Hand: A Security Analysis and Defense Framework for OpenClaw》基于 47 个对抗场景做了量化测试，结论很明确：模型选择直接影响安全性。Claude Opus 4.6的原生防御率为 83%（配合人工审批可达 91.5%），而 DeepSeek V3.2 仅为 17%——所有 Base64/hex 编码绕过均通过。两者之间存在 66 个百分点的差距。
─── 写在最后 ───
调研完这一圈，小编最大的感受是：OpenClaw 只有在危险的时候才有用。
如果你启用沙箱、禁用网络、移除文件写入权限、关闭自主执行——安全了，但你基本上重建了一个需要自托管的 “ChatGPT”。这是 AI agent 安全的根本悖论：实用性和安全性在当前技术水平下几乎是零和博弈。
从积极面看，OpenClaw 团队对安全问题的响应速度值得肯定——关键漏洞通常在 24-72 小时内修复。但从架构层面看，24/7 后台运行 × 50+ 平台集成 × 完整系统权限 × 持久化记忆，构成了 Palo Alto Networks 所称的”致命四角”——这些不是可以通过补丁修复的架构性问题。
所以小编的建议是：可以玩，但一定在隔离环境中玩。专用机器、独立账号、最新版本、不装未审查的 skill——做好这些，再去享受 AI agent 的魔力。