乐于分享
好东西不私藏

龙虾OpenClaw有多少安全漏洞被修过

龙虾OpenClaw有多少安全漏洞被修过

# 养龙虾之前,先看看官方修了哪些安全漏洞

"龙虾"火了,但没人告诉你它被修了多少个安全漏洞。

最近这篇《OpenClaw安全使用指南》在网上广泛流传,文章列举了AI智能体的几类风险:权限失控、恶意扩展、公网暴露。读来有些抽象,仿佛是对着空气讲道理。

我决定换个角度,直接翻一翻OpenClaw(即Hermes Agent)的官方更新记录,看看开发者自己在过去几个版本里修了哪些真实漏洞——那些记录,比任何风险提示都更直观。

官方在修什么漏洞

以下内容均来自Hermes Agent(OpenClaw的上游开源项目)v0.8和v0.9的公开更新日志,均有对应PR编号可查。

SMS远程代码执行(RCE)

v0.9修复了一个Twilio短信webhook的签名验证缺失问题(PR #7933)。

这意味着什么?如果你配置了SMS接入,任何人只要能向你的webhook地址发送一条特定格式的HTTP请求,就能以你的身份向AI下达指令。不需要密码,不需要你的手机,只需要一个网络请求。

修复之前,这是一个真实存在的远程代码执行向量。

Shell注入

v0.9修复了沙箱写入操作中的路径注入问题(PR #7940):当文件路径包含特殊字符时,原有代码会将其直接传入Shell命令,攻击者可借此执行任意系统命令。

路径穿越

v0.9同时修复了检查点管理器中的路径穿越漏洞(PR #7944),以及技能管理器操作中的路径边界绕过(PR #7156)。

路径穿越的意思是:本来只能读取某个目录下的文件,但通过构造"../../etc/passwd"这样的路径,就能读到不该读的地方。

SSRF(服务端请求伪造)

v0.8和v0.9均有SSRF修复记录。

v0.9修复了Slack图片上传功能中的SSRF重定向绕过(PR #7151);v0.8进行了一次集中的SSRF防护整合(PR #5944)。

SSRF的危害在于:攻击者可以操纵服务器向内网地址发起请求,用来探测内网拓扑,或访问云服务商的元数据接口(比如AWS的169.254.169.254),从而窃取实例凭证。

API服务器未授权访问

v0.9新增了API绑定保护(PR #7455):对非本地回环地址的绑定,强制要求配置API_SERVER_KEY。

翻译成人话:如果你的OpenClaw对外网开放了API接口,但没有设置访问密钥,之前任何人都能调用。现在会强制要求你设密钥。

审批按钮绕过

v0.9修复了会话审批授权问题(PR #6930):危险操作的"审批"按钮此前缺乏身份验证,任何人都可以点击确认。

这个漏洞的背景是:OpenClaw执行危险操作前会弹出审批请求,本意是让用户确认。但如果这个按钮没有鉴权,那么任何能看到这条消息的人(比如群里的其他成员)都能替你"点同意"。

v0.8:MCP扩展恶意包扫描

v0.8引入了MCP扩展包的自动恶意软件扫描(PR #5305),接入了OSV漏洞数据库,在安装第三方扩展时自动检测已知恶意包。

这直接对应了流传文章中的"恶意扩展"风险点。

对照来看

把上面这些漏洞对照那篇《安全使用指南》里的风险清单:

"管理权限失控"——shell注入、路径穿越都是典型案例,攻击者通过构造输入来劫持已有的高权限。

"防护门槛降低"——MCP恶意包扫描正是官方对这个风险的直接回应。

"提供入侵通道"——API服务器未授权访问、Twilio SMS RCE,都是公网暴露场景下的真实入侵通道。

这不是巧合,这就是真实的威胁模型。

这说明什么

有人会说,开源项目公开漏洞修复记录是正常操作,不代表特别危险。

这个说法没错。但我想强调的是另一面:这些漏洞之所以被发现并修复,恰恰说明有人在认真做安全审计。v0.9的发布说明里,开发者自称这是"史上最深度的安全加固",并不是夸口,而是有具体PR支撑的陈述。

真正值得警惕的,反而是那些什么漏洞记录都没有的项目——不是因为它们没有漏洞,而是因为根本没人在找。

普通用户怎么办

几条实际可操作的建议,比"绷紧安全之弦"更具体:

关于部署环境:不要在存有核心工作数据的主力机上直接部署。用一台专用设备或虚拟机,隔离风险边界。

关于公网暴露:如果你不需要从外网访问,就不要开公网端口。如果必须开,务必配置API_SERVER_KEY,并启用HTTPS。

关于扩展安装:只从官方渠道安装扩展。v0.8之后的版本已有自动恶意包扫描,确保你用的是较新版本。

关于第三方安装服务:购物平台上那些"上门部署"服务,你交出的不只是设备,还有AI的所有访问权限。装完之后你很难验证里面是否有后门。极不推荐。

关于版本更新:安全漏洞的修复都在更新里,保持更新是最低成本的安全措施。

最后说一句

每一个被修复的漏洞背后,都有一个曾经存在的攻击面。

在这些漏洞被修复之前部署了旧版本的用户,并不知道自己在承担什么风险。这才是真正值得重视的地方——不是对AI能力的恐惧,而是对版本管理和配置规范的忽视。

技术本身并不是敌人,疏于维护才是。