开放与安全的博弈:OpenClaw爆火后的安全挑战

2026年伊始，OpenClaw成为了开源社区和AI圈最火的话题, OpenClaw主打面向个人电脑的智能体，吸引了大量科研工作者、企业员工、甚至普通消费者的目光，在国内还出现了互联网大厂集中线下安装OpenClaw的营销活动，“养龙虾”一时成为时髦。不夸张地说，OpenClaw成为了继DeepSeek之后又一个春节档现象级AI事件。

OpenClaw开源项目始于2025年11月，短短数月Github项目的Star数过32万，在已然非常拥挤的AI智能体赛道迅速脱颖而出，引发了行业的极大关注。OpenClaw大火的原因除了其用户使用体验良好、结果令人满意之外，主要归功于其开放性，特别是在能力开放、生态开放和权限开放，如图1所示。

• 能力开放，用户能够快速调用已有技能（skill）或创建新的技能，自主地完成特定功能。

以往同样功能的实现需要大量人的参与，而借助大模型的思维链和海量技能库，OpenClaw就能够自主地规划执行路径、执行指令和闭环目标。

• 生态开放， OpenClaw生态中的技能通过仓库分发快速传播、改进和增强。

目前OpenClaw的技能仓库ClawHub已有超过2.8万个技能，用户可以查询或下载技能。OpenClaw与CrawHub的关系，就如同Android操作系统与应用商店，两者形成了互相促进的生态体系，而且用户自己就可以成为技能的开发者，不断地提升技能的数量和质量。

• 权限开放，用户可以高权限执行技能，默认配置下执行命令时不会受到额外的约束，能完成更多样性、更复杂的任务。

当前已有大量开源和商业的AI智能体项目，一类如千问、豆包APP上的应用智能体，主要是运行在应用层，执行特定的模型或算法输出结果；一类是Manus、HaloMate等云端智能体，除了做模型的上下文工程外，还可以调用工具，但这些过程都是在云端的沙箱环境中，不会影响本地环境；还有一类如Claude Code、Gemini CLI这些本地智能体，本地智能体能操作的资源比应用层和云端智能体更多更底层，不过这些智能体仅能读写特定目录下的文件，所有操作前需要得到用户的授权，所以我们称之为“本地受限智能体”。而OpenClaw在默认配置下是对智能体调用技能、命令执行是不加限制也无需授权的，可以称为“本地全能智能体”。

OpenClaw智能体一方面极大降低了软件功能实现的技术难度，通过技术平权提升了不同行业对软件革命的预期；另一方面，OpenClaw的安全问题从一开始就引发了安全社区的关注。

 如前所述，OpenClaw爆火的原因是能力开放、生态开放和权限开放，而恰恰是这三个开放导致了极大的安全风险。  首先是能力开放，用户即便没有编程经验，通过氛围编程（vibe coding）就可以自制技能，但是这些自制技能会调用系统命令或访问第三方系统的服务，而系统的整体设计、命令和服务的调用过程是否存在安全风险是未知的。比如2026年1月，仅依靠氛围编程实现的agent社区Moltbook出现150万核心凭证泄露的严重安全风险，原因仅仅是AI在实现业务逻辑时没有生成数据库行级安全策略（RLS）代码[1]。

其次是生态开放，用户即便没有现成的技能，也可以通过CrawHub找到合适的技能。但是任何人都可以向CrawHub上传技能，自然也包括攻击者。事实上，根据软件安全公司Snyk的研究，ClawHub上大量技能存在安全风险[2], 如果攻击者事先投放包含恶意代码的技能，而用户或OpenClaw安装了这些恶意技能，结合OpenClaw自身漏洞或不完备的安全机制，就容易触发恶意代码的执行。

最后是权限开放，正所谓能力越大，责任也越大。OpenClaw与应用智能体、云端智能体和本地受限智能体相比，OpenClaw能访问在资源、能调用的命令和执行的权限都更大，但在默认配置下其权限管控策略当前却是理想的。

大模型技术时至今日，其智能程度毋庸置疑，从技术角度看，智能体早就可以做非常多有创造力的事情了，但影响智能体的发展的重要因素无外乎“开放“与“安全”两词,开放性带来的风险是智能体固有的特点，上述风险并非OpenClaw独有。开放性带来安全风险，安全顾虑有可能会制约发展。

有的智能体期望从开放性破局。2025年12月，豆包手机助手发布，可视为“移动终端上的OpenClaw”，马上出现了包手机助手与微信之争，引发社会广泛关注。CCF YOCSEF于2026年1月举办的 “微信等'封杀'豆包手机助手，根因与未来？” 特别论坛，与会专家讨论激烈，剖析了其中深层逻辑，其中豆包智能体的数据隐私与系统安全风险确实存在，而事关商业利益与入口主权的生态之争同样至关重要，智能移动终端的生态开放性不够，被各种超级App分割。因而，生态不够开放、安全顾虑凸显成为移动终端智能体的制约因素。

总而言之，开放和风险是OpenClaw的一体两面，正如开放窗户带来了新鲜空气，但同样也会引来蚊子苍蝇。安全风险也是我们无法回避的现实，只有了解风险，理解风险，才能管理风险。

笔者通过智能体（Gemini CLI）收集了OpenClaw开源项目的安全问题，至2026年3月19日共271条，并进行分析。

从时间轴上看， 公告发布日期呈现明显的阶梯式增长趋势，如表1所示。其中2025年主要在项目初期，月均2-3条，多为低风险配置问题。2026 年 1 月由于开始引入 AI 智能体执行框架，漏洞数量跃升至 45 条。2026 年 2 月进入高峰期。单月披露 128 条公告，主要集中在 system.run 和沙箱环境的指令完整性验证。

漏洞类型分布如表2所示，大部分漏洞能造成越权执行或任意代码执行，危害极大。

从漏洞严重程度看，严重加高危占比为70%，这反映了 OpenClaw 作为一个 AI 智能体框架，其核心功能（执行系统指令和管理敏感 API）具有极高的天然风险，任何微小的逻辑疏忽都可能演变为严重的安全事件。而且，攻击面集中在“边界”：严重漏洞主要发生在 插件集成和外部 Webhook 处，这些地方是 AI 与外部系统交互的关口，也是最容易出问题的地方。

绿盟科技在《2026网络安全趋势报告》[3]中指出，智能体的自主决策特性放大了供应链风险。当用户从不可信来源安装Skill时，无异于主动把家门钥匙交给陌生人。此类风险涉及身份伪造、决策失控、数据泄露、模型漏洞等多个层面。

OpenClaw的供应链风险主要体现在ClawHub中第三方技能，其安全性同样堪忧。2026年2月，软件安全公司Snyk对ClawHub 和 skills.sh 站点中的 3984 个技能进行研究，发现13.4% (534个) 的技能包含严重级别的安全问题，包括恶意软件、凭据窃取和提示词注入，36.8% (1,467个) 的技能存在至少一个安全漏洞（如硬编码 API 密钥）[2]。目前，仓库中技能数量在2026 年初呈指数级增长，这势必引起大量恶意攻击者的关注。

2020年，Solarwind公司被入侵植入恶意代码，恶意软件造成了包括美国国防部在内两百多家重要机构失陷，软件供应链攻击已经成为当前网络空间对抗的重要技战术。而在人工智能时代，可以预见以技能投毒为代表的AI供应链攻击也将成为常态。

就桌面智能体而言，其操作敏感程度使得商业公司的智能体产品更多考虑安全性。如Claude、Google等公司已经推出了Claude Code、Gemini CLI本地智能体，可配合各类第三方skill。但出于数据安全、系统安全的考虑，这类智能体设计之初的授权策略即为“零信任”，即默认配置下不具备执行命令的权限，当且仅当需要执行某条命令时，才需要用户显式授权。

而OpenClaw则默认是“全授权”机制，这种计算机系统对智能体“门户大开”的策略，使其极富创造性，也极易闯祸，“OpenClaw确实开放，但确实不安全”的特点造成了现在对其评价两极分化严重的现象。图2就展示了默认配置下用户指示OpenClaw与Gemini CLI删除文件的不同处理逻辑，OpenClaw默认没有启用黑白名单所以直接删除文件，而Gemini CLI则需得到用户授权才能查看并删除文件。

2026年3月，工业和信息化部网络安全威胁和漏洞信息共享平台（NVDB）发布了预警[4]：OpenClaw开源AI智能体部分实例在默认或不当配置下存在严重安全风险，极易引发网络攻击、信息泄露等安全问题。可见此类安全风险已经引起国家有关部门的重视。

短短3个月，我们已经看到不少OpenClaw相关的安全事件[5]，从攻击面暴露到远程代码执行，从研究发现的安全风险到真实发生的恶意事件，OpenClaw相关的安全问题已是刻不容缓。

2026年1月底2月初，人们纷纷尝鲜安装OpenClaw，但安装的服务OpenClaw Gateway默认监听所有网络接口的18789端口，而有些安装的服务因种种原因直接暴露在互联网上。在2026年1月至2月期间，全球范围内暴露在互联网上的OpenClaw实例高达13.5万余个，其中1.2万余个存在远程代码执行的漏洞，这些未受保护的节点吸引着大量的自动化漏洞扫描与攻击[6]。

2026年3月20日，网络空间测绘系统Shodan显示监听互联网上国内暴露的OpenClaw服务为6.8万（指纹提取自18789端口banner），绿盟威胁情报显示国内OpenClaw服务暴露数量为6.5万余（指纹提取自5353端口banner），如图3所示（注：Shodan中18789端口暴露数总数为24.7万，但具体产品之和远少于总数，可能原因是Shodan产品识别不够精确，故取暴露数量而非已识别的产品数量）。

2026年1月底至2月中旬，OpenSourceMalware与Trend Micro公司在监控中发现了一场隐蔽的供应链协同攻击，这次大规模投毒事件被命名为“ClawHavoc”[7]。

在ClawHavoc投毒事件中，以ID为hightower6eu的攻击者在短时间内上传了高达1184个恶意Skill，如图4所示。这些Skill被伪装成各类高频应用工具，如“Twitter/X社交管理助手”、“PDF长文档摘要生成器”、“多功能天气预报”等。

与传统的二进制病毒不同，这些恶意Skill将自然语言的描述文本、环境配置文件以及可执行脚本混合打包。为了绕过早期的自动化静态扫描，攻击者采用了一种被称为“ClickFix”的社工方法。攻击者不会直接将恶意代码在组件的说明文件（如SKILL.md或者初始化脚本）中，而是伪造环境依赖安装说明，从而诱导用户在终端中手动运行包含Base64编码或混淆后的脚本指令。用户一旦运行，实际上便将恶意代码植入到了OpenClaw的运行环境中。

一旦诱导执行成功，恶意代码便被激活，攻击者根据目标系统的不同，投递多样化的恶意载荷，收割macOS系统的钥匙串、浏览器密码、加密货币钱包资产与软件会话，或者窃取受害者的Claude或OpenAI等付费AI大模型的API密钥。

从技术手段上看，攻击者不再单纯依赖二进制病毒，而是利用大模型无法区分指令与数据，实施间接提示注入，而且有指令执行是在本地运行，云端大模型并不能完全预测和感知到本地的异常行为，造成了安全防护的盲区。

2026年2月中旬，网络安全公司Hudson Rock在监控全球受感染设备的数据回传流量时，检测到一个包含完整.openclaw目录的ZIP压缩包。经逆向分析，该恶意软件被证实为窃密木马Vidar的新变种[8]。这一发现首次确认了针对OpenClaw的定向窃密攻击。

通常Vidar木马的扫描模块会扫描Chrome等浏览器软件中的敏感信息（如cookie），但该变种添加了OpenClaw本地目录扫描的能力，当该木马在受害者主机部署后，会扫描并识别~/.openclaw目录中的配置、公私钥、访问凭证和存储信息（如memory），如图5所示。进而木马将敏感数据外传，可以为后续的社会工程提供丰富的上下文情报。

需要警惕的是当AI成为电脑操作的决策者，那么它既有权限也有可能删除电脑中的某些重要文件。无论是模型本身的能力不足还是出现幻觉，或是智能体系统设计有bug，又或者有恶意攻击，那么OpenClaw一定会在未来的某刻犯错。

2026年2月，Meta超级智能的安全对齐负责人Summer Yue在X发文[9]，她用测试OpenClaw的邮件自动整理功能时，遇到了严重失控事件，如图6所示。OpenClaw强行删除其邮箱内200多封邮件，原因是邮箱数据量过大触发了 OpenClaw 的上下文压缩（context compaction）机制，导致初始安全指令在处理过程中丢失，AI 自行执行了批量删除。这被视为 AI Agent 工具在实际大上下文场景下的典型风险案例。

新技术的出现，不可避免地带来了新的风险，关注OpenClaw的风险，并非要阻碍其应用，而是通过了解其安全问题后做有针对风险管理，这样才能有助于我们更好地发挥OpenClaw的生产力。

首先，OpenClaw自身的安全问题暴露非常多，安全社区一直致力于修复相关安全问题，公开漏洞前提供安全修复方案。广大OpenClaw的使用者应当持续升级到最新版本，避免自身漏洞被利用。

其次，CrawHub上的第三方技能工具存在恶意代码的可能，为此CrawHub集成了OpenClaw社区和VirusTotal的技能扫描工具，对上架的技能进行代码分析，一方面给出技能的能力边界，如调用指令的范围，另一方面识别技能是否存在权限提升、访问凭证、下载恶意代码等风险。用户应当根据扫描提示谨慎确定是否要使用这些技能。

最后，OpenClaw的安全治理需要多种手段的结合。例如遵循NIST CSF网络安全框架，在识别环节，应当使用网络全流量、终端安全产品通过网络流量特征、终端行为识别企业内部环境中已安装OpenClaw的端点；在防护环节，通过配置检查和加固等方式，消减已知漏洞的安全风险[10]；在运行环节，将技能扫描、下载和调用嵌入到整个智能体执行环节，对可疑的网络和终端行为进行阻断；在响应环节，考虑对安全事件进行溯源分析，将被破坏的重要系统、文件还原。

发展与安全如何平衡，始终是个人、社会和国家面临的问题。人工智能已是发展的必选项，但人工智能伴生的安全风险管理同样重要。网络安全行业经过多年实践，已经达成了一个共识：安全应当成为系统的内生特性，安全设计应当与软件设计同步，安全能力应当与软件功能生命周期同步。那么人工智能要做到高质量发展，学术界同仁应攻关人工智能内生安全的科学问题，突破面向人工智能软件供应链的安全防护技术；而产业界同仁应当构建面向人工智能生态完整的安全架构、关键技术和能力体系。

本公众号原创文章仅代表作者观点，不代表绿盟科技立场。所有原创内容版权均属绿盟科技研究通讯。未经授权，严禁任何媒体以及微信公众号复制、转载、摘编或以其他方式使用，转载须注明来自绿盟科技研究通讯并附上本文链接。