[分享]针对openclaw的深入研究

一、产品概述
OpenClaw是一个AI代理网关，核心功能是将大语言模型（如GPT、Claude）的能力通过多种消息平台（如Telegram、Discord、Slack等）提供给用户，并支持执行本地命令、文件操作等。其定位类似于 Claude Code，采用“用户即管理员”的信任模型，专为本地或私有化部署设计。
二、产品影响AI 智能体 OpenClaw 自 2026 年 1 月正式发布后，凭借原生的本地应用操控能力与轻量化的端云协同架构，精准填补了大模型 “能思考难执行” 的落地空白,快速引爆市场成为现象级产品，吸引国内外各大厂商争相入局布局。
截至2026年2月6日，github 星标数已突破 16.8万。
三、工作原理
OpenClaw 的核心工作原理是通过一个网关架构Gateway，将用户在不同消息平台上的指令，转化为对应用系统的操作。
OpenClaw的所有消息渠道、客户端、设备节点都通过 WebSocket 与网关通信，实现「消息统一接入 - 智能处理 - 多端响应」的全流程，核心分 3 步：
1.多渠道消息接入：WhatsApp/Telegram/微信/钉钉等各类通讯渠道的消息，会统一推送到 Gateway 网关；
2. 智能处理：网关将消息转发给 AI 代理（Agent），结合配置的大模型（Anthropic/OpenAI 等）、技能（Skills）、工具（Browser/Canvas 等）完成思考和处理；
3.多端响应执行：处理结果可通过原渠道回复，也能下发给 macOS/iOS/Android 等设备节点，执行本地操作（如摄像头、录屏、系统通知）。
四、部署模式OpenClaw 通过单个 Gateway 网关进程将聊天应用连接到 Pi 等编程智能体。它为 OpenClaw 助手提供支持，并支持本地或远程部署。
OpenClaw部署安装后，具备Web控制界面，用于聊天、配置、会话和节点的管理。
▪本地默认地址为：ce0K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8U0p5J5y4#2)9J5k6e0m8Q4x3X3f1H3i4K6u0W2x3g2)9K6b7e0p5^5y4K6R3&6 ▪远程访问Web界面如下：
五、现有安全机制
OpenClaw的现有安全机制主要有沙盒机制（基于路径限制而非Docker）、工具白名单/黑名单（Tool Policy）、命令执行审批流程（Ask Mode）以及针对外部内容的提示词注入（PI）检测模块。
沙盒路径限制
工具执行安全策略（白名单机制）权限验证逻辑
六、存在问题分析OpenClaw构建了一套以本地单用户可信为核心假设的安全机制，其存在明显的安全问题。沙盒机制仅依赖路径限制，无法防御内核级攻击；工具白名单易被编码命令绕过；审批流程在自动化场景下形成瓶颈；最关键的是，其提示词注入检测模块仅防护外部内容，却默认完全信任已认证用户的输入，导致来自核心交互路径（如chat.send）的恶意指令可长驱直入。
这些问题的本质在于失衡的信任模型。系统将复杂的内部威胁简单等同于外部威胁进行防护，忽视了已认证通道可能被劫持或滥用的风险。关键问题在于：安全机制高度依赖“用户即管理员”这一理想假设，一旦该假设在多用户或高权限场景下被打破，整个防护体系便出现致命短板。（一）官方安全立场与局限性
OpenClaw在SECURITY.md中明确将“Prompt injection attacks”列为Out of Scope事项，其安全模型基于两个核心假设：▪仅考虑本地单用户部署场景▪默认认证用户即为可信管理员这种立场导致系统存在根本性设计缺陷：当部署场景超出预设范围（如多用户环境或公网暴露）时，安全边界将完全失效。已有实际案例表明，攻击者可通过SSRF漏洞绕过本地部署限制，将本应隔离的本地API暴露为攻击入口。（二）提示词注入防护的体系性缺陷
从安全设计的角度来看，OpenClaw在SECURITY.md 中明确声明：“Prompt injection attacks” 被列为“ Out of Scope”，即不被列入安全问题。
从防护体系的角度来看，OpenClaw内置的提示词注入模块由external-content.ts 模块实现，在系统中的应用防护覆盖不全。下表详细说明了 external-content.ts安全模块的核心函数及其在系统中的应用情况。其安全防护的覆盖也存在差异，具体如下：从技术实现的角度来看，external-content.ts 模块的检测逻辑依赖正则匹配，无语义分析，缺少对编码指令、多步攻击的检测。
external-content.ts 模块的检测模式SUSPICIOUS_PATTERNS部分内容如下：
/ignore\s+(all\s+)?(previous\|prior\|above)\s+(instructions?\|prompts?)/i/system\s*:?\s*(prompt\|override\|command)/i/\bexec\b.*command\s*=/i/you\s+are\s+(now\s+)?a/i, /act\s+as\s+(if\s+you\s+are\|a)/i
（三）沙盒机制存在突破风险
OpenClaw实现了路径沙箱机制，主要通过resolveSandboxPath函数进行路径解析和逃逸检测。
但是这种沙箱机制能够防御../类路径遍历，但无法防范：▪ /proc/self/environ等特殊文件系统访问▪文件描述符泄露导致的沙箱逃逸
OpenClaw的沙盒机制本质上是基于路径的访问控制列表，而非真正的进程隔离（如Docker使用的命名空间和cgroups技术）。它试图通过控制文件路径来划定边界，但操作系统提供的许多访问渠道（如特殊文件系统、文件描述符、链接）都可以绕过这一单薄的防御层。
（四）MCP原则的架构性失效
OpenClaw现有的MCP防护措施是命令白名单，但是其存在安全失效的场景，具体如下：
究其原因，是因为OpenClaw在架构层面系统性违背了最小权限原则，导致其安全控制存在根本性缺陷。其权限体系在多个关键层面存在过度授权问题，具体如下：
通过分析OpenClaw的关键配置，发现其存在执行权限的“全有或全无”问题。

七、风险作证
（一）经CVE编号的漏洞清单
以下漏洞已被正式分配CVE编号，表明其安全风险已得到官方确认。获得CVE编号意味着这些漏洞具有明确的公共影响力，其分析需遵循标准框架。
▪CVE-2026-25253 (Critical): 此漏洞是典型的“一键RCE”漏洞，影响2026年1月29日之前的所有版本。由于其利用复杂度低且无需认证，在公网暴露场景下可直接导致系统沦陷。▪CVE-2026-25157 (High): 该漏洞破坏了沙盒隔离的基本假设，即使部署在受信网络内，攻击者也可通过读取配置文件（如~/.openclaw/openclaw.json）获取更多敏感信息，辅助后续攻击。▪CVE-2026-24763 (Medium): 信息泄露漏洞本身不直接导致代码执行，但泄露的会话ID、内部路径等元数据，极大地辅助了攻击者进行目标

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-290139.htm