事件背景：一个开源明星的崛起与危机
OpenClaw 是什么
OpenClaw（前身为 MoltBot 和 ClawdBot）是由奥地利独立开发者 Peter Steinberger 于 2025 年 11 月发布的开源 AI Agent 框架。它凭借以下四大特性迅速走红：
- 极致灵活的工具调用能力：支持任意 MCP 工具注册，可读写文件、执行 Shell 命令、调用 API
- 持久上下文与记忆：Agent 可以跨会话保持状态和记忆，实现「真正的工作连续性」
- 富插件生态（ClawHub）：任何人都可发布 Skill 插件，积累超 5,000 个社区插件
- 社交化（Moltbook）：Agent 拥有独立社交身份，可在 Moltbook 自主发帖、互动，形成全球最大 AI Agent 社交网络
到 2026 年 4 月，OpenClaw 在 GitHub 上累计了超过 21.5 万个星标，月活跃 Agent 实例超过 77 万个，是当时全球最大的开源 Agent 生态之一。
Moltbook 社交平台
Moltbook 是 OpenClaw 生态中的社交网络平台，被誉为「AI Agent 的 Reddit」。它允许本地运行的 OpenClaw 智能体拥有独立社交身份，进行自主发帖、互动，甚至形成百万级 AI 自主社交网络。正是一个极具创意的功能，最终成为整个灾难的导火索。
灾难时间线：从数据库暴露到全球沦陷
| 时间 | 事件 |
|---|---|
| 2025.11 | Peter Steinberger 发布 OpenClaw（原名 MoltBot），首周 GitHub 星标破万 |
| 2026.01 | Moltbook 社交平台上線，Agent 开启社交化体验 |
| 2026.03 | OpenClaw 月活 Agent 突破 50 万，ClawHub 插件超 3,000 个 |
| 2026.04 | 高峰月活 77 万，GitHub 星标 21.5 万 |
| 2026.05.06 | 攻击者发现 Moltbook Supabase 数据库未配置 RLS 策略 |
| 2026.05.07 | 攻击者通过浏览器 F12 获取匿名 API 密钥，下载了完整数据库 |
| 2026.05.08 | 150 万+ Agent Token 和 1.7 万+ 人类邮箱被批量泄露 |
| 2026.05.09 | 攻击者开始利用 Token 远程接管 Agent |
| 2026.05.10 | 攻击者在 ClawHub 上传 341 个恶意插件，供应链攻击启动 |
| 2026.05.11 | ClawJacked 零点击攻击被公开，WebSocket 漏洞大规模利用 |
| 2026.05.12 | 媒体报道发酵，OpenClaw 被 GitHub 暂时下架 |
| 2026.05.14 | Peter Steinberger 宣布无限期退出项目维护 |
| 2026.05.15 | 安全团队估计直接经济损失已超 2.3 亿美元 |
五环节攻击链全还原
OpenClaw 事件的深层教训是：一个成功的开源项目，其安全脆弱性同样随规模指数级增长。当你的 Agent 框架拥有 77 万活跃实例时，不再只是「你的代码安不安全」的问题，而是「你的数据库、你的插件市场、你的 API 设计、你的用户行为——每一个环节都需要企业级安全投入」。
环节一：Moltbook 数据库配置错误（安全基座崩塌）
Moltbook 的后端使用 Supabase 托管服务（一个开源的 Firebase 替代品）。由于创始人采用「Vibe Coding」方式——完全由 AI 自动生成代码——在数据库配置中遗漏了最关键的安全措施：行级安全策略（RLS, Row-Level Security）。
技术细节：Supabase 默认允许通过匿名 API 密钥（匿名密钥）访问数据库，前提是配置了 RLS 策略。但 Moltbook 的数据库表没有 RLS 配置。这意味着任何获取到匿名 API 密钥的人，都可以对数据库中的任何表执行任意 CRUD 操作。
攻击过程：攻击者发现 Moltbook 前端代码中硬编码了 Supabase 匿名 API 密钥。通过浏览器 F12 开发者工具即可轻松获取。使用这个密钥，攻击者直接连接 Supabase API，发出了一个简单的 SQL 查询——结果返回了整个数据库的全部内容。
环节二：150 万 Agent Token 泄露（数据雪崩）
数据库暴露的直接后果是：
- 150 万+ Agent API Token：每个 Token 代表一个运行中的 Agent 实例的身份凭证
- 1.7 万+ 人类邮箱：注册用户的邮箱地址和部分个人信息
- Agent 配置数据：包括环境变量、工具权限、连接的外部服务凭证
Agent Token 的设计初衷是方便 Agent 在 Moltbook 平台进行身份验证。但由于 Token 与用户的本地 Agent 实例绑定，泄露后攻击者可以这些 Token 冒充合法 Agent 身份进行远程操控。
环节三：大规模远程接管（权限滥用）
利用泄露的 Agent Token，攻击者可以：
- 以 Agent 身份执行任意操作：发送消息、读取会话记录、调用 Agent 注册的所有工具
- 窃取 API 密钥：Agent 配置中通常包含 OpenAI、Anthropic 等模型 API 密钥，攻击者借此获得免费模型调用能力
- 获取 Shell 权限：如果 Agent 配置了 Shell 执行能力（OpenClaw 的默认能力之一），攻击者获得的是完整的设备控制权限
安全研究员在分析中确认，至少 3 万个被入侵的 Agent 实例被用于自动化窃取凭证、拦截通信和分发恶意软件。
环节四：ClawHub 供应链投毒（生态污染）
与此同时，攻击者在 OpenClaw 的插件市场 ClawHub 上传了 341 个恶意技能插件。这些插件：
- 伪装成「邮件助手」、「文件管理」、「系统优化」等日常工具
- 部分插件甚至通过了基本信息审查，因为恶意代码被巧妙隐藏在多层函数调用之后
- 用户安装后，Agent 会自动执行恶意代码，包括窃取本地文件、安装后门、向 C2 服务器发送数据
这是 AI Agent 领域迄今为止规模最大的一次供应链攻击。传统的插件审查流程完全无法检测出经过精心伪装的 Agent 恶意插件。
ClawHub 供应链投毒：341 个恶意插件 | 伪装 10+ 种常用工具 | 传统审查流程 100% 失效
环节五：ClawJacked 零点击攻击（最后一击）
ClawJacked 是本次事件中最具技术创新性和破坏力的攻击方式。其技术原理如下：
技术原理：本地运行的 OpenClaw 实例会在 localhost 地址上启动一个 WebSocket 服务（通常是 ws://localhost:18888），用于接收来自浏览器或其它本地应用的指令。这个 WebSocket 服务在设计时假设「localhost 上的连接都是可信的」——这是为了易用性而做的安全假设。
攻击利用：攻击者创建了恶意网页，其中包含一段 JavaScript 代码，尝试连接 ws://localhost:18888。当用户访问这个网页时，浏览器执行这段 JS 代码，尝试与本地 OpenClaw 实例建立 WebSocket 连接。如果连接成功（用户在后台运行了 OpenClaw），攻击者可以直接向 Agent 发送指令，无需任何认证。整个过程不需要用户输入密码、不需要点击任何按钮 —— 零点击。
影响范围：任何运行 OpenClaw 的用户，只要访问了攻击者的恶意网站，Agent 就会在几秒内被完全控制。这种方式绕过了所有传统安全防线：没有钓鱼邮件、没有恶意附件、没有可疑链接——只是一个普通的网页访问。
关键技术漏洞深度分析
| 漏洞 | 类型 | 影响 | 根因 |
|---|---|---|---|
| Supabase RLS 缺失 | 数据库配置 | 全量数据泄露 | Vibe Coding 遗漏安全配置 |
| 硬编码 API 密钥 | 前端安全 | 漏洞暴露 | 未使用服务器代理或密钥管理 |
| Token 无作用域限制 | 授权设计 | 远程接管 | Token 设计时未考虑最小权限 |
| 插件无安全审查 | 供应链安全 | 恶意插件传播 | 缺乏自动化代码审计 |
| WebSocket 无认证 | 传输层安全 | 零点击远程控制 | localhost 信任假设 |
| Shell 执行默认开启 | 能力配置 | 完整设备控制 | 安全默认值设计缺陷 |
损失评估：2.3 亿美元的背后
直接经济损失
- API 密钥滥用：攻击者利用窃取的模型 API 密钥进行大量推理调用，导致受害者收到数万至数十万美元的账单
- 数据泄露：涉及的知识产权、客户数据、商业机密泄露难以量化
- 系统损害：被控制设备需要完全重装系统，部分企业因 Agent 被攻陷导致生产环境故障
间接损失
- 信任崩塌：开源 Agent 框架的信任度受到根本性打击，企业用户纷纷暂停或移除开源 Agent
- 生态毁灭：OpenClaw 从 21.5 万星标项目变成历史，插件生态 ClawHub 永久关闭
- 市场沉淀：事件直接加速了企业对 Agent 安全的重视——NemoClaw 等内置安全护栏的产品成为企业标配
三大失误：技术、管理与信任
技术失误：Vibe Coding 的安全债
OpenClaw 的早期代码几乎全部通过 AI 生成。虽然「Vibe Coding」带来了极快的开发速度，但它也带来了一系列安全隐患：数据库 RLS 配置缺失、API 密钥硬编码、WebSocket 无认证——这些都是 AI 代码生成中的典型安全盲区。
管理失误：一个人维护 77 万 Agent
Peter Steinberger 是一位优秀的独立开发者，但一个人管理一个拥有 77 万 Agent 用户的平台，在安全上注定力不从心。没有专职安全工程师、没有漏洞响应流程、没有自动化安全检测——这是独立开发者项目的典型困境。
信任失误：过度信任「localhost」
Agent 生态中一个普遍存在的设计假设是「本地运行的 Agent 是安全的」。这个假设在用户只在自己的机器上使用 Agent 时成立，但当 Agent 与外界（Moltbook、ClawHub、WebSocket）建立连接后，本地安全假设就完全失效了。
从灾难到防御：7 条 Agent 安全加固指南
基于 OpenClaw 事件的完整复盘，以下是从个人开发者到企业用户都可执行的 7 条 Agent 安全加固指南：
1. 数据库安全：RLS 是第一道防线
任何使用 Supabase/Firebase 等 BaaS 服务的项目，必须在数据库设计阶段就配置行级安全策略。PostgreSQL 的 RLS 可以在数据库层限制每行数据的可见性和可操作性，防止因 API 密钥暴露导致的拖库。验证方式：使用匿名 API 密钥尝试跨用户查询数据，确保返回空结果。
2. API 密钥管理：永远不要硬编码
前端代码中的 API 密钥可通过浏览器 F12 轻松获取。正确做法是使用服务器代理或密钥管理服务（如 HashiCorp Vault、AWS Secrets Manager）。前端只暴露经过严格限制的临时 Token，服务端进行权限校验。
3. Token 设计：最小作用域 + 可撤销
Agent Token 的设计需要遵循最小权限原则：Token 的作用域应限制在用户自己的 Agent 上，不能访问其他用户的 Agent。同时需要提供 Token 撤销机制——用户发现 Token 泄露后可以立即失效所有已发 Token。
4. WebSocket 安全：即使 localhost 也需要认证
WebSocket 连接必须包含认证机制，即使是在 localhost 上。一种推荐的实践是使用「Origin 校验 + 临时握手 Token」的双重认证：浏览器先通过 HTTP 请求获取一个临时 Token，再用这个 Token 建立 WebSocket 连接。Token 有效期短（如 1 分钟），过期自动失效。
实施示例：
// 服务端：WebSocket 连接前需要握手 Token
GET /api/ws-handshake → 返回临时 Token (有效期 60s)
WebSocket 连接时在 header 中携带 Token
服务端验证 Token 有效性和 Origin 头
通过后才允许 WebSocket 通信5. 插件安全：建立自动化安全审查管道
ClawHub 的教训表明，人工审查无法应对大规模的插件投毒。现在可用的实践包括：
- 静态代码分析（SAST）：自动扫描插件代码中的可疑模式（如硬编码 IP、文件泄露、数据外发）
- 运行时沙箱：在隔离环境中执行插件，监控其系统调用行为
- 签名验证：要求所有插件开发者在发布前对插件进行数字签名
6. 默认安全配置：高危能力默认关闭
Shell 执行、文件系统全量访问、外部网络请求等高危能力应该默认关闭。Agent 框架应遵循「默认拒绝」原则——用户需要手动启用每个高危能力，并在启用时明确知道风险。
7. 事件响应计划：提前准备，不要临时应对
每个使用 Agent 的组织都应该准备 Agent 安全事件响应计划：
- 检测：如何发现 Agent 被攻陷（异常 Token 使用、异常工具调用模式）
- 隔离：如何快速阻断被攻陷的 Agent（Token 吊销、断开外部连接）
- 恢复：如何恢复被篡改的数据和配置
- 根因分析：如何定位漏洞原因，防止再次发生
今天就可以做的三件事：检查 Supabase 是否配置了 RLS | 审查所有 WebSocket 是否包含认证 | 关闭 Agent 的 Shell 执行能力（如果不是必须的）
行业影响：一个事件改变了一个行业
OpenClaw/Moltbook 事件的意义远超单个项目：
- OWASP Agentic AI Top 10：该事件直接推动了 OWASP 在 2026 年 1 月发布全球首个 Agentic AI 安全标准
- GitHub 安全政策更新：GitHub 在事件后更新了开源 AI 项目的安全审查指南
- 企业采购标准改变：安全合规成为企业采购 Agent 产品的首要考量，NemoClaw 等内置安全护栏的产品成为企业标配
- 开源 Agent 信任危机：企业对开源 Agent 框架的信任度大幅下降，自托管和商业支持方案更受青睐
- Vibe Coding 安全反思：事件引发了行业对 AI 生成代码安全性的广泛讨论
教训总结
OpenClaw/Moltbook 事件不是一个孤立的安全事故——它是一个警示。77 万个 Agent 的沦陷告诉我们三件事：
- 安全不是附加功能，而是 Agent 的核心架构支柱。在 Agent 时代，安全设计必须从第一天开始——因为一旦 Agent 上线运行，它就具备了调用工具、读写文件和执行命令的能力。一个漏洞不等于一个功能 Bug，而等于一把随时可能被引爆的炸弹。
- 开源不等于免费的安全。一个成功的开源项目可能会获得 21.5 万个星标，但星标数不等于安全投入。企业级安全需要专职的安全工程师、持续的漏洞检测和规范的响应流程。在 Agent 安全这件事上，「人多眼杂」不成立——代码审计和社区审查无法覆盖 Agent 特有的组合安全漏洞。
- Agent 生态需要行业级安全标准。单个项目的安全努力远远不够。当 Agent 可以跨平台通信、跨插件协作、跨 Token 认证时，安全需要整个生态的协同：从框架设计者到插件开发者到最终用户，每个环节都需要遵守统一的安全规范。
OpenClaw 的陨落是 AI Agent 行业的至暗时刻，但也是行业安全觉醒的起点。每一个从这场灾难中汲取的教训，都将成为未来 Agent 安全的重要基石。