今天聊一个严肃的话题。2026年2月份OpenClaw爆出了一个SSRF漏洞，在安全圈引起了不小的关注。我当时正好在帮公司维护OpenClaw实例，第一时间跟进了这个事件，把整个过程复盘一下分享给大家。
漏洞是怎么回事
简单来说，这是一个服务端请求伪造（SSRF）漏洞。攻击者可以通过精心构造的AI对话内容，让OpenClaw服务端去请求攻击者指定的内部网络地址。
漏洞的根源在于OpenClaw在处理用户输入中包含的URL时，没有做充分的校验和过滤。比如用户在对话中输入一个URL让AI去访问，OpenClaw会直接发起请求，而没有检查这个URL是否指向了内部网络地址（比如127.0.0.1、192.168.x.x、169.254.169.254等）。
这意味着攻击者可以利用这个漏洞去探测OpenClaw所在服务器的内网环境，访问云服务商的元数据接口获取密钥，甚至进一步发起对内网其他服务的攻击。
影响范围有多大
理论上所有暴露在公网的OpenClaw实例都受影响。这里的关键词是"暴露在公网"——如果你的OpenClaw只在内网使用并且有防火墙保护，风险就小得多。
但现实情况是，很多人为了方便远程访问，直接把OpenClaw的端口开放到了公网，而且没有加任何认证。更夸张的是，有安全研究员用Shodan扫描了一下，发现了大量完全裸奔的OpenClaw实例。这些实例不仅没有认证，有些甚至连基本的HTTPS都没有配置。
这就很恐怖了。这意味着任何人都可以直接访问你的OpenClaw，不仅能看到你的对话历史，还能利用SSRF漏洞去攻击你的内网。
漏洞是怎么被发现和修复的
这个漏洞最早是社区的一个安全研究员在做代码审计时发现的，他负责任地通过安全邮件报告给了OpenClaw团队。OpenClaw团队在收到报告后大概48小时内就发布了修复版本，响应速度还是挺快的。
修复方案也比较直接：在URL请求层面增加了地址校验，禁止访问内网地址段和特殊地址。同时还增加了请求频率限制和超时控制，防止通过大量请求来探测内网。
我的应急处理过程
说说我自己当时是怎么处理的。
第一时间我做了三件事：一是把OpenClaw的公网端口临时关掉，只保留内网访问。二是检查了访问日志，看有没有异常的请求模式。三是通知了团队暂时不要使用。
检查日志的时候确实发现了一些可疑的请求，有几个请求试图访问AWS的元数据接口169.254.169.254，这是典型的SSRF攻击特征。好在我们的服务器设置了IMDSv2，所以这些请求没有成功获取到敏感信息。但想想还是有点后怕。
确认没有被实质性攻击之后，我升级了OpenClaw到最新版本，重新配置了网络策略，然后才恢复了服务。
防范建议
经过这次事件，我总结了几条OpenClaw安全部署的建议，希望对大家有帮助。
第一，绝对不要把OpenClaw直接暴露在公网。如果需要远程访问，用SSH隧道。这是最基本的安全原则，但偏偏很多人为了图方便就忽略了。
第二，前面加一层Nginx反向代理和认证。就算因为某些原因必须公网可访问，也至少要在前面加一层HTTP Basic Auth或者更高级的认证方式。Nginx的配置很简单，网上教程一搜一大堆。
第三，配置防火墙规则。限制OpenClaw只能访问必要的外网地址，禁止它访问内网地址段。这样即使存在SSRF漏洞，攻击者也无法利用它来探测你的内网。
第四，定期更新版本。OpenClaw的更新迭代很快，安全修复通常会包含在版本更新中。不要因为"能用就行"而一直停留在老版本上。建议至少每两周检查一次有没有新版本。
第五，监控异常访问日志。设置一些基本的告警规则，比如短时间内大量请求、访问异常URL等。很多问题如果能早发现就能避免更大的损失。
第六，做好网络隔离。OpenClaw应该部署在一个独立的网络段，不要和数据库、核心业务系统放在同一个网段。这样即使OpenClaw被攻破，攻击者也很难横向移动到更重要的系统。
安全意识比技术更重要
说到底，这次事件暴露出的最大问题不是技术层面的漏洞，而是安全意识的缺失。很多人部署OpenClaw的时候完全没考虑过安全问题，把它当成一个内部小工具随便一放就完了。
开源软件好用，但安全责任完全在自己身上。不像SaaS服务有厂商帮你兜底，自建服务的安全是自己的事。
我建议每个自建OpenClaw的人都做一个简单的安全检查清单：端口有没有暴露在公网？有没有认证机制？版本是不是最新的？有没有监控告警？日志有没有定期检查？
花不了多少时间，但可能帮你避免一次严重的安全事故。
大家的OpenClaw实例安全配置做得怎么样？有没有遇到过安全相关的问题？特别是用云服务器部署的同学，你们有没有做网络隔离？欢迎交流一下各自的安全实践。