你上一次不假思索地将整个数字生活的钥匙交给一个软件智能体是什么时候?对于成千上万的开发者和高级用户来说,那一刻随着去年 11 月 OpenClaw 的发布而到来。它承诺了一个无摩擦的未来:AI 可以为你购物、整理文件并管理你的 Slack 频道。但正如我们本周所了解到的,这种便利伴随着危险的代价。
一个多月以来,安全社区一直在鸣响警钟。OpenClaw 在 GitHub 上获得了惊人的 347,000 颗星,其设计初衷是充当数字代理。为了发挥效用,它需要对已登录的会话、本地网络文件和敏感通信平台进行深度且普遍的访问。从设计上讲,它的构建是为了绕过传统手动任务管理的摩擦。然而,最近修复的一个漏洞(CVE-2026-33579)已将该代理变成了潜在的数字特洛伊木马。
在架构层面,OpenClaw 依靠配对系统来授权新设备。Blink 的研究人员发现的这个漏洞看似简单,却极具杀伤力。它允许拥有最基础权限(称为 operator.pairing 范围)的用户悄悄提升其状态。
在实践中,攻击者可以发送一个看似无害但请求 operator.admin 权限的配对请求。由于应用程序在验证这些请求时存在系统性缺陷,权限提升在没有任何二次验证的情况下发生了。奇怪的是,除了初始握手之外,不需要任何用户交互。从终端用户的角度来看,一切看起来都很正常,而攻击者实际上已经拿到了王国的万能钥匙。
我多年来一直在分析复杂的 APT 攻击,这次特定的漏洞利用让我想起了经典的“电梯故障”逻辑:你按下了去大堂的按钮,但系统却让你绕过安全磁卡阅读器,直接到达顶层公寓。在 AI 智能体的世界里,顶层公寓包含着你的关键任务数据、私人消息和存储的凭证。
从风险角度来看,这一漏洞的影响怎么强调都不为过。当我们谈论权限提升时,通常将其视为长链条中的一个步骤。而在这里,提升本身就是链条。一旦攻击者获得了 OpenClaw 实例的管理访问权限,他们不仅仅是在沙箱内部;他们是以宿主用户的完整权限在运行。
对于企业环境来说,这在数字层面相当于石油泄漏。损害并不仅限于初始受影响点。具有管理员权限的攻击者可以读取连接的数据源,从智能体的技能环境中窃取存储的凭证,并转向其他连接的服务(如 Jira 或 AWS)。由于 OpenClaw 被设计为一个强大的助手,它的内存中通常已经存储了各种 API 的“钥匙”。
最终,这个漏洞导致了整个实例被接管。在过去的一个月里,可能有数千个实例遭到破坏,而且由于该漏洞利用非常隐蔽,许多用户可能仍未意识到他们的数字代理一直在为他人效力。
这一事件是一个完美的教训,说明了为什么我们需要以一种健康的偏执心态来对待 AI 智能体。我们通常将这些工具视为有用的伙伴,但在安全背景下,它们代表了攻击面的大规模扩张。我们应该将零信任视为操作系统每个内门处的 VIP 俱乐部保镖。仅仅因为你让 AI 进入了俱乐部,并不意味着它在没有对其凭证进行持续、细粒度重新验证的情况下,就应该拥有进入后台办公室的权限。
OpenClaw 的开发人员已经发布了补丁,但撇开补丁不谈,根本问题仍然存在:我们授予自主智能体的权力,超出了我们当前安全框架所能监控的范围。在监管背景下,这引发了关于数据完整性和未经授权访问的重大问题。如果一个 AI 智能体因为被攻破而代表你执行了恶意操作,谁该负责?
如果你是将 OpenClaw 集成到工作流中的 347,000 名用户之一,你的第一步显而易见:立即更新到最新版本。然而,如果船只在设计上就容易进水,仅仅堵住船壳上的洞是不够的。我们需要重新思考如何隔离这些智能体。
从主动防御的角度来看,组织应采取以下步骤来降低代理式 AI 的风险:
当我们在这个新领域航行时,必须记住,隐私和安全不仅仅是合规性的复选框——它们是 AI 时代信任的基石。我们不能让对自动化的渴望超过我们对稳健防御的承诺。
来源:



