夜雨聆风你的 AI 助手，正在替攻击者干活。
这不是危言耸听。4月9日，OpenClaw 官方仓库紧急发布了一批安全补丁，其中有一条——编号 PR #63226，级别 Critical——让所有自建 AI 助手的开发者心头一紧：
OpenClaw 内置浏览器的 SSRF 隔离机制，被交互操作绕过了。
也就是说，当你的 AI 助手受你操控浏览网页时，它本不该访问内网敏感资源——但攻击者可以诱导它"点击"一个链接，让它悄悄替你扫描内网，把结果老老实实汇报给攻击者。
更关键的是：这个问题 4月8日才修复，4月9日才发版。如果你还没升级，你的助手可能就是"内鬼"。
SSRF 隔离是什么
SSRF，全称 Server-Side Request Forgery（服务器端请求伪造）。
用人话讲：本来你的服务器只应该访问 A 网站，但攻击者让它偷偷访问了 B 网站，而且是你不知道的情况下。
在 OpenClaw 的场景里，浏览器是 AI 助手的"眼睛"。助手需要浏览网页、抓取页面内容、填表单——这些都依赖浏览器组件。
OpenClaw 为了安全，给浏览器配了一套隔离名单（quarantine），把内网地址、S3 元数据端点（169.254.169.254）、K8s API 等列为禁区。助手想访问这些地址？直接被拦截。
这次出问题的，就是这道防线。
漏洞原理
OpenClaw 原来的 SSRF 检查逻辑：
用户打开网页 → 检查 URL 是否在隔离名单 → 通过 → 页面加载成功
这套机制在页面初始加载时工作正常。但 AI 助手的浏览器不只是"打开网页"——它还要点击链接、运行 JavaScript、执行自动化操作。
这些交互行为触发的页面导航，没有再次执行 SSRF 检查。
具体哪些交互会绕过检查？
- click：助手点击了一个按钮或链接
- evaluate：助手通过 JavaScript 触发了页面跳转
- hook-triggered click：助手响应某个 hook 事件执行的点击
- batched action：批量操作中的一次导航
攻击者只需要构造一个恶意网页，里面放一个指向内网地址的链接（比如 http://169.254.169.254/latest/meta-data/），然后诱导 AI 助手去"点击"它。
初始页面加载没问题，但点击链接的一瞬间——隔离检查被跳过了，内网大门敞开。
攻击链还原
完整攻击链条如下：
第一步：攻击者给受害者发一条消息，或者让受害者访问一个恶意网页（钓鱼链接、恶意插件、或者是别人写的一个看起来无害的 skill）
第二步：网页里暗藏一个链接，指向内网地址，比如 http://169.254.169.254/latest/meta-data/，这是 AWS S3 / 云服务器的元数据端点，里面往往有机密凭证
第三步：AI 助手被操控，用 click/evaluate 等方式"点击"了这个链接
第四步：导航触发，SSRF 检查被绕过，助手成功访问了内网敏感资源
第五步：AI 助手把访问结果返回给攻击者，攻击者拿到云凭证、内网拓扑、API 密钥等敏感数据
整个过程，受害者完全不知情。AI 助手只是在"正常浏览网页"，但实际上已经成为攻击者的内网扫描工具。
图：攻击链路三阶段——恶意网页诱导点击 → SSRF 检查被绕过 → 内网数据泄露
漏洞有多严重
利用门槛
从技术角度看，攻击者不需要越狱、不需要 root、不需要特殊权限，SSRF 检查的绕过完全在合法交互范围内。
但前提是：受害者必须主动或被动地触发某个交互操作——比如点击了钓鱼链接、安装了恶意 skill。这让实际攻击仍依赖一定的社工手段。
影响范围
OpenClaw 支持 Discord、Telegram、Slack 等多渠道接入，浏览器是跨渠道的核心能力。只要你的 AI 助手配置了浏览器功能，且尚未升级到 4月9日之后的新版，就存在这个风险。
潜在危害
访问 AWS IMDS 元数据端点（169.254.169.254）可以获取云服务器凭证和 IAM 角色信息；访问 K8s API 可以获取集群配置信息；访问内网数据库可以读取业务数据。
一旦攻击者拿到这些，服务器权限、数据库拖库、云账号接管——全部成为可能。
官方修复
4月8日，OpenClaw 提交了 PR #63226，核心修复思路是：在所有 interaction-driven navigation 全流程，重新执行 blocked-destination 检查。
图：PR #63226 修复方案——全链路 SSRF 导航守卫，覆盖 click/evaluate/hook-click/batched-nav 四条路径
具体措施包括：
增加导航守卫：在 click/evaluate/hook-triggered click 等所有交互触发路径上，统一加装 SSRF 检查关卡
延长守卫有效期：覆盖完整 action 周期，防止检查在执行过程中过期
同 URL 去重：对重复导航请求做去重，避免因重复检查导致的性能损耗
忽略 hash-only 变化：same-document 的纯锚点变化（如 #section）不触发检查，减少误判
该修复已于 2026年4月9日 正式发布，版本已合入 main 分支。
你现在该做什么
P0——立即升级
执行以下命令，今天就做，这是唯一真正有效的办法：
openclaw upgrade
P1——检查工作区环境变量
确认你的工作区目录下没有被人悄悄写入恶意的 .env 文件，尤其注意这些前缀的变量：GATEWAY_*、OPENCLAW_*、browser.control.*
P1——审计已安装插件
openclaw plugins list
移除来源不明的插件，不给攻击者可乘之机。
P2——审查配对节点
检查已配对的移动端/远程节点，确认没有陌生设备。如果有设备丢失过，尽快解绑。
写在最后
OpenClaw 是目前最流行的自托管 AI 助手方案之一，这次安全漏洞的修复速度算是快的——从发现到合入再到发布，总共没几天。
但这个漏洞本身，折射出一个更根本的问题：当 AI 助手拥有了浏览器的执行权，你的信任边界到底应该画在哪里？
AI 助手不只是你的助手，它也是一个拥有系统权限的自动化程序。你给它开放了多少能力，就等于给潜在攻击者开放了多少攻击面。
开浏览器之前，先想清楚：这个助手到底能访问什么？
参考来源
[1] PR #63226 - OpenClaw SSRF Fix | OpenClaw GitHub，2026.04.08（https://github.com/openclaw/openclaw/pull/63226）
[2] OpenClaw 2026.04.09 Release（含全部安全修复）| OpenClaw GitHub，2026.04.09（https://github.com/openclaw/openclaw/releases）
[3] OpenClaw 安全公告报告规范 | OpenClaw GitHub，持续更新（https://github.com/openclaw/openclaw/security）
[4] openclaw/trust 威胁模型 | OpenClaw Trust，2026.02.04（https://github.com/openclaw/trust）
