OpenClaw爆火的原因是能力开放、生态开放和权限开放，而恰恰是这三个开放带来了极大的安全风险。
春节过后“养龙虾”成风，OpenClaw开放爆火出圈
2026年伊始，OpenClaw成为了开源社区和AI圈最火的话题。OpenClaw主打面向个人电脑的智能体，吸引了大量科研工作者、企业员工甚至普通消费者的目光，一时间“养虾”成风。不夸张地说，OpenClaw成为了继DeepSeek之后又一个春节档现象级AI事件。
OpenClaw开源项目始于2025年11月，短短数月，其Github1项目的Star数超过了32万，在已然非常拥挤的AI智能体赛道迅速脱颖而出，引发了行业的极大关注。OpenClaw大火的原因除了其用户使用体验良好、结果令人满意之外，还归功于其开放性，特别是在能力开放、生态开放和权限开放方面，如图1所示。
能力开放：用户能够快速调用已有技能（skill）或创建新的技能，自主地完成特定功能；
生态开放：OpenClaw生态中的技能通过仓库分发快速传播、改进和增强，目前OpenClaw的技能仓库ClawHub已有超过2.8万个技能，用户可以查询、下载甚至改进技能，技能数量和质量不断提升；
权限开放：用户可以高权限执行各种技能和系统指令，能完成更多样、更复杂的任务。
图1 开放的OpenClaw实现复杂任务
OpenClaw智能体一方面极大降低了软件功能实现的技术难度，通过技术平权提升了不同行业对软件革命的预期；但另一方面，OpenClaw的安全问题从一开始就引发了安全社区的担心。
天下没有免费的午餐，OpenClaw的开放带来了风险
如前所述，OpenClaw爆火的原因是能力开放、生态开放和权限开放，而恰恰是这三个开放带来了极大的安全风险。
能力开放 用户即使没有编程经验，也可自制技能，但这些自制技能的设计和实现、指令调用过程是否存在安全风险是未知的。比如2026年1月，仅依靠氛围编程（Vibe Coding）实现的Agent社区Moltbook出现150万份核心凭证被泄露的严重安全风险，原因仅仅是AI在实现业务逻辑时没有生成数据库行级安全策略（RLS）代码。
生态开放 用户即便没有现成的技能，也可以通过ClawHub找到合适的技能。但是任何人都可以向ClawHub上传技能，自然也包括攻击者。事实上，根据软件安全公司Snyk的研究，ClawHub上的大量技能存在安全风险，如果攻击者事先投放包含恶意代码的技能，而用户或OpenClaw安装了这些恶意技能，结合OpenClaw自身漏洞或不完备的安全机制，就容易触发恶意代码的执行。
权限开放 OpenClaw与应用智能体、云端智能体和本地受限智能体相比，OpenClaw拥有更强的资源访问能力、更大的命令调用和执行的权限，但在当前默认配置下其权限管控策略却不尽理想。
开放和风险是OpenClaw的一体两面，正如开放窗户带来了新鲜空气，但同样也会引来蚊子苍蝇。安全风险也是我们无法回避的现实，只有了解风险、理解风险，才能管理风险。
OpenClaw的安全风险一览
OpenClaw自身代码的安全风险
笔者收集并分析了OpenClaw开源项目中的271条安全公告(截至2026年3月19日)。从时间轴上看，公告发布日期呈现明显的阶梯式增长趋势，其中2025年主要在项目初期，月均2~3条，多为低风险配置问题；2026年1月由于开始引入AI智能体执行框架，漏洞数量跃升至45条；2月进入高峰期，单月披露128条公告，主要集中在system.run和沙箱环境的指令完整性验证。如表1所示，从已公开的安全公告分析，严重加高危漏洞占比为70%，可见作为一个AI智能体框架，OpenClaw的核心功能，如执行系统指令和管理敏感API，具有极高的天然风险，任何微小的逻辑疏忽都可能演变为严重的安全事件。
表1 OpenClaw的安全漏洞严重程度分布
第三方技能的安全风险
OpenClaw的技能仓库ClawHub中第三方技能的安全性堪忧。2026年2月，软件安全公司Snyk对ClawHub和skills.sh站点中的3984个技能进行研究，发现13.4%（534个）的技能包含严重级别的安全问题，包括恶意软件、凭据窃取和提示词注入；36.8%（1467个）的技能存在至少一个安全漏洞（如硬编码API密钥）。目前，仓库中技能数量在2026年初呈指数级增长，这势必引起大量恶意攻击者的关注。可预见，以技能投毒为代表的AI供应链攻击也将成为常态。
不当配置所造成的安全风险
就桌面智能体而言，其操作敏感程度使得商业公司需要对其智能体产品的安全性有更多的考虑。如Claude、Google等公司已经推出了Claude Code、Gemini CLI本地智能体，可配合各类第三方技能。但出于数据安全、系统安全的考虑，这类智能体设计之初的授权策略为“零信任”，即默认配置下不具备执行命令的权限，当且仅当需要执行某条命令时，才需要用户显式授权。
而OpenClaw则默认是“全授权”机制，不限制系统命令执行（截至2026年3月19日）。图2展示了默认配置下用户指示OpenClaw与Gemini CLI删除文件的不同处理逻辑，Gemini CLI须得到用户授权才能查看并删除文件，而OpenClaw默认没有启用黑白名单而直接删除文件，可见其授权机制过于粗放。
图2 OpenClaw与Gemini CLI删除文件的处理逻辑对比
3月，工业和信息化部网络安全威胁和漏洞信息共享平台（NVDB）发布了预警：OpenClaw开源AI智能体部分实例在默认或不当配置下存在严重安全风险，极易引发网络攻击、信息泄露等安全问题。智能体安全风险已经引起国家有关部门的重视。
OpenClaw安全事件频发
短短3个月，我们已经看到不少OpenClaw相关的安全事件，从攻击面暴露到远程代码执行，从研究发现的安全风险到真实发生的恶意事件，解决OpenClaw相关的安全问题刻不容缓。
OpenClaw实例在互联网暴露，进而成为被攻击目标
2026年1月底2月初，人们纷纷尝鲜安装OpenClaw，但安装的服务OpenClaw Gateway默认监听所有网络接口的18789端口，有些服务未加防护就直接暴露在互联网上。3月20日，绿盟威胁情报显示，国内OpenClaw服务暴露数量已超过6.5万，居全球第一，如图3所示。这些未受保护的节点吸引着大量的自动化漏洞扫描与攻击。
图3 OpenClaw服务暴露面（2026年3月20日）
恶意技能泛滥引发安全事件，智能体漏洞与传统软件漏洞无本质区别
2026年1月底至2月中旬，OpenSourceMalware与Trend Micro公司在监控中发现了一场隐蔽的供应链协同攻击，这次事件被命名为“ClawHavoc”。ID为hightower6eu的攻击者在短时间内上传了多达1184个恶意技能，这些技能伪装成各类高频应用工具，如Twitter/X社交管理助手、PDF长文档摘要生成器、多功能天气预报等，如图4所示。
图4 上传到CrawHub的恶意技能
攻击者在恶意技能中伪造环境依赖安装说明文件（内含Base64编码或混淆后的脚本指令），诱导用户在终端中手动运行，一旦运行即可将恶意代码植入OpenClaw的运行环境。随后攻击者可根据不同目标系统投递多样化的恶意载荷，收割macOS系统的钥匙串、浏览器密码和加密货币钱包资产。
如果OpenClaw能删除你的重要文件，那就一定会
当OpenClaw具备操作系统高权限后，它就有可能删除电脑中的某些重要文件。究其原因，可能是模型本身的能力不足或出现幻觉，可能是智能体系统设计存在缺陷，也可能是遭受了恶意攻击。
2026年2月，Meta超级智能的安全对齐负责人Summer Yue在X发文，她在测试OpenClaw的邮件自动整理功能时，遇到了严重的失控事件，如图5所示。OpenClaw强行删除其邮箱内200多封邮件，原因是邮箱数据量过大而触发了OpenClaw的上下文压缩机制，导致初始安全指令在处理过程中丢失。这被视为AI Agent工具在实际大上下文场景下的典型风险案例。
图5 OpenClaw违背指令删除邮件
要安全也要生产力，养好虾的对策
新技术的出现，不可避免地带来了新的风险，关注并理解OpenClaw的风险，做有针对性的风险管理，方能更好地发挥OpenClaw的生产力。
首先，OpenClaw自身的安全问题暴露非常多，安全社区一直致力于修复相关安全问题，广大用户应当持续升级到最新版本，避免自身漏洞被利用。
其次，ClawHub现已集成了VirusTotal等技能扫描工具，可移除恶意技能，标记可疑技能。用户应当根据安全提示谨慎使用相关技能。
最后，OpenClaw的安全治理需要结合多种手段。事前使用网络全流量、终端安全产品识别企业内部环境中已安装OpenClaw的节点；通过配置检查和加固等方式，提前消减已知漏洞的安全风险。事中将技能扫描、下载和调用嵌入到整个智能体执行环节，在大模型边界部署安全围栏，对可疑行为进行阻断。
人工智能需要良性发展，开放与安全既是博弈也是互利。安全应当成为开放系统的内生特性，安全设计应当与软件设计同步，安全能力应当与软件功能生命周期同步，软件系统应当同时做到“安全原生”和“AI原生”。学术界同仁应攻关人工智能内生安全的科学问题，突破面向人工智能软件供应链的安全防护技术；产业界同仁应当构建面向人工智能生态完整的安全架构和能力体系。
注：
1 https://clawhub.ai/
刘文懋
CCF杰出会员、理事。绿盟科技首席创新官，星云实验室负责人。主要研究方向为云计算安全、人工智能安全与数据要素安全。
点击“阅读原文”，加入CCF。