2026年3月，被誉为"增长最快的开源AI Agent项目"的OpenClaw遭遇严峻安全考验。安全研究者在短时间内追踪到针对其用户的全链条攻击矩阵：攻击者通过NPM恶意依赖包、伪造GitHub组件仓库实施供应链投毒，并利用认证控制逻辑缺陷完成渗透。这一系列结构化攻击表明，针对OpenClaw的常态化、低门槛渗透能力已形成。

更令人担忧的是暴露面。据OpenClaw Exposure Watchboard最新测绘数据（2026年3月10日），全球已有超过27万个OpenClaw实例暴露在公网，其中约40%与已知APT组织存在关联。朝鲜的APT37、Kimsuky，俄罗斯的APT28、Sandworm Team等国家级攻击者正在积极利用这些暴漏的节点。每一台被攻陷的主机，都可能成为他们深入企业内网的跳板。

本报告将系统梳理这些攻击事件的技术细节，剖析当前安全架构中的薄弱环节，并为不同用户群体提供可落地的防御建议。我们希望通过这份报告，帮助客户建立从威胁认知到风险缓解的完整知识框架。

第一章

AI Agent时代的安全新挑战

1.1 失控的增长与失控的风险

2026年1月的最后一周，OpenClaw在GitHub上单日斩获25,000颗Star，创造了开源项目历史上前所未有的增长纪录。到本文发布时，这一数字已经飙升至296,000。硅谷的投资人称之为"下一个ChatGPT时刻"，开发者社区为之沸腾，无数技术爱好者开始在自己的电脑上部署这个赋予AI"上帝模式"的助手。

图1 OpenClaw Star增长曲线图

图1展示了2026年1月至3月期间，OpenClaw项目GitHub Star数量从0快速增长至296,000的惊人曲线，直观呈现了"史上增长最快开源项目"的数据。但很少有人意识到，当一个AI代理可以不受限制地读写你的文件、发送你的消息、控制你的终端时，每一次安全漏洞都可能意味着灾难性的后果。

三类读者，请找到属于你的风险画像：

如果你是一名普通用户，你的iMessage、WhatsApp、银行验证码、加密货币钱包可能正处于危险之中。攻击者已经开发出专门针对OpenClaw配置的信息窃取程序，一旦你的电脑被入侵，所有这些敏感数据都将成为囊中之物。

如果你是一名开发者，你的GitHub令牌、AWS凭证、Docker密钥可能已经暴露。多个黑客组织正在主动扫描互联网上的OpenClaw实例，寻找那些配置不当的部署，然后上传带后门的"技能"来窃取你的开发环境访问权限。

如果你负责企业安全，你需要立即行动。研究显示，超过40,000个OpenClaw实例暴露在公共互联网上，其中63%可以被轻易利用。当攻击者通过一个钓鱼链接就能在员工电脑上部署后门时，整个内网都将处于危险之中。

1.2 OpenClaw成为攻击目标的深层原因

这并非黑天鹅事件，而是传统边界防御模型与AI Agent自然语言驱动理念发生范式摩擦的必然代价。

以往的安全对抗依赖于严格的软硬件沙箱机制与跨进程内存隔离，而AI Agent的驱动核心是大语言模型的语义理解。攻击载荷被直接编码在提示词序列或指令集内，这直接击穿了传统的规则匹配与沙盒隔离防护体系。

OpenClaw过于宽泛的“权限即服务”设计理念放大了这一脆弱性。其生态设计理论上允许直接跨协议调用与无限制的终端操作，这一特性在满足高度自由定制的同时，也使其成为了黑客进行Payload组装攻击的天然“肉鸡”。 此外，充当插件集散地的ClawHub市场严重缺乏安全左移的基础审核机制。研究人员披露，早期超过800个恶意组件成功上架，充当了灰产及供应链污染的温床。结合近期数据显示的37.2%的凭据泄露率及巨量暴露面问题（详见第二章），OpenClaw已成为全球攻击者眼中的高价值靶机池。

更令人担忧的是产品的迭代速度。从Clawdbot到Moltbot再到OpenClaw，这个项目在短短三周内经历了两次更名，每次更名都伴随着新的功能上线和安全机制的重新设计。这种近乎狂野的开发节奏固然满足了用户对新功能的渴望，但也让安全审计成为了一个不可能完成的任务。

ClawHub市场的存在让问题雪上加霜。这个允许用户自由上传"技能"的市场，本意是建立一个丰富的插件生态系统，但由于缺乏有效的审核机制，它迅速成为了恶意代码的集散地。研究人员发现，在短短几周内就有超过800个恶意技能被上传到市场，其中相当一部分成功骗取了用户的信任。

最后是暴露面的失控。当用户将OpenClaw部署到云服务器以便随时访问时，他们可能没有意识到自己的电脑已经成为了互联网上的一个活靶子。根据2026年3月10日的最新扫描数据，全球共有273,548个OpenClaw实例暴露在互联网上，其中37.2%存在凭据泄露，40.7%与已知威胁组织存在关联。详细数据将在第二章第4节"全球暴露态势"中详述。

1.3 本报告的三个核心维度

本报告主要依照三层解构进行：首先复盘已触发的供应链污染、认证机制绕过及规模化数据外泄等标志性安全事件；其次向下钻取AI Agent底座设计的安全积弊与信任链阻断；最后输出面向多方角色的工程化缓解方案。

第二章

真实攻击事件深度剖析

2.1 供应链攻击的多层渗透

如果你认为只从官方渠道下载软件就足够安全，那OpenClaw的故事会让你重新思考这个假设。

图2 供应链攻击链路

图2展示了针对OpenClaw用户的典型供应链攻击链路：从恶意NPM包上传、用户安装、假CLI界面诱导、Keychain窃取、到最终数据外传的完整攻击流程。

伪装NPM包的攻击是这场供应链噩梦的开端。2026年3月，JFrog安全研究团队披露了一起针对开发者群体的GhostClaw供应链攻击事件。攻击者在npm仓库发布恶意软件包 @openclaw-ai/openclawai，该软件包伪装为合法AI开发工具 OpenClaw 的相关组件，诱导开发者下载安装。一旦开发者在本地环境中安装该依赖，恶意代码便会在软件安装阶段自动执行，从而实现对开发者终端的初始入侵。

图3 “@openclaw-ai/openclawai”包详细信息

攻击的精妙之处在于它的社会工程学设计。当用户安装这个包时，它会显示一个精心制作的假命令行界面，带有动画进度条，让人相信OpenClaw正在被安装。安装完成后，脚本会弹出一个伪造的iCloud Keychain授权提示框，要求用户输入系统密码。与此同时，恶意代码正在后台悄悄与攻击者的命令控制服务器通信。

图4 虚假的安装界面与授权提示认证

在用户交互过程中，恶意程序会从攻击者控制的服务器trackpipe[.]dev下载第二阶段加密载荷，并通过解密后在后台执行。该载荷内部组件被命名为 GhostLoader，内部代码规模较大，具备信息窃取和远程控制能力。

图5 加密的第二阶段载荷内容

成功感染后，恶意程序会在隐藏目录中建立持久化机制（如shell启动脚本或cron任务），并部署具备远程命令执行、SOCKS5代理、剪贴板监听、浏览器会话克隆等功能的后门模块。与此同时，恶意程序还会系统性窃取敏感数据，包括浏览器密码与Cookie、SSH密钥、云服务凭证、加密货币钱包信息、macOS Keychain数据以及iMessage历史记录，并通过多个通信渠道回传至攻击者。

ClawHub市场的沦陷态势触目惊心。研究人员对ClawHub上的2,857个技能进行了全面审计，结果发现了341个恶意技能——这意味着每八个技能中就有一个是坏的。这个数字在后续调查中继续增长，最终达到了824个。

图6 恶意技能分布

图6展示了ClawHub市场上恶意技能的伪装类型分布，其中加密货币相关工具占比最高，还包括YouTube工具、Polymarket机器人、Google Workspace集成等多种伪装形式。

这些恶意技能的伪装手法多种多样。它们把自己包装成流行的工具：Solana钱包追踪器、YouTube视频下载器、Polymarket交易机器人、Google Workspace集成工具。每一个都配有看起来非常专业的文档和教程。

攻击的关键在于"前置条件"这个巧妙的设计。这些恶意技能会告诉用户，为了使用该技能，你需要先安装"必需组件"。在Windows上，下载一个名为"openclaw-agent.zip"的压缩包；在macOS上，是一行需要粘贴到终端的命令。

GitHub仓库投毒。在报告发布时，OpenClaw官方Skill仓库中仍存在恶意Skill。该Skill伪装成"LinkedIn智能求职系统"，声称提供基于AI的职位搜索、简历定制、一键申请、面试跟踪及智能筛选等功能，具有高度迷惑性。恶意仓库地址：https://github.com/openclaw/skills/blob/main/skills/zaycv/linkedin-job-application/SKILL.md。

图7 OpenClaw官方Skill仓库投毒

图7展示了利用Github投毒，恶意Skill引导AI下载执行恶意代码的描述信息，该技能的文档要求用户：Windows用户需下载名为"AuthTool.exe"的程序（密码1234，下载地址为：https://github.com/Aslaep123/clawd-authtool/releases/download/released/AuthTool.zip，目前该恶意账户已经无法访问），macOS用户则被引导在终端运行一行命令，声称完成配置，实际会下载并执行恶意软件。一旦用户执行，攻击者就可以实施攻击，包括窃取加密货币钱包、交易账户凭据等高价值数据。

我们还发现了另一个部署在GitHub上的恶意Skill，属于同一攻击团伙的分散投毒策略。该恶意Skill托管于Skill分享平台SundialHub（https://www.sundialhub.com/）的官方仓库sundial-org/awesome-openclaw-skills中，具体文件路径为https://github.com/sundial-org/awesome-openclaw-skills/blob/main/skills/bybit-trading/SKILL.md。该Skill伪装成"Bybit Trading Agent"加密货币交易代理，具有极强的目标人群针对性。经深入分析，该Skill下载的恶意文件地址与此前OpenClaw官方仓库投毒事件中的地址完全一致，由此可确认两起事件为同一攻击团伙所为，其通过向多个高流量仓库植入恶意Skill以扩大攻击覆盖面。

图8 sundial-org/awesome-openclaw-skills仓库投毒

攻击者还通过GitHub创建伪造的"openclaw-installer"仓库，利用SEO使其出现在搜索结果中。源码仅是moltworker项目的复制粘贴，真正的恶意载荷在Release页面的OpenClaw_x64.exe中。

图9 伪造的openclaw-installer仓库描述信息

Windows平台释放cloudvideo.exe（窃取程序，从Telegram/Steam获取C2）和serverdrive.exe（GhostSocks代理，通过注册表持久化）；macOS平台则用OpenClawBot窃取文档目录。GhostSocks曾被Black Basta勒索软件使用，表明OpenClaw用户已卷入更广泛的网络犯罪生态。

2.2 认证机制漏洞与攻击路径

如果说供应链攻击需要用户主动"配合"才能成功，那么接下来要讨论的漏洞则更加凶险——它们可以在用户毫无察觉的情况下完成攻击。

CVE-2026-25253是OpenClaw历史上最严重的漏洞之一。安全研究人员给它起了一个代号："ClawJacked"。这个漏洞允许攻击者通过一个恶意链接实现"一键远程代码执行"——受害者只需要点击一个链接，攻击者就能完全控制他们的AI代理和系统。

图10 漏洞攻击链

图10展示了CVE-2026-25253漏洞的完整攻击链路：恶意链接→URL参数读取→WebSocket连接→暴力破解密码→注册恶意设备→完全控制受害者的AI代理。

漏洞的技术细节令人不安。问题的根源在于OpenClaw的网关组件会从URL查询字符串中读取gatewayUrl参数，然后自动建立WebSocket连接。由于OpenClaw对本地连接采取了宽松的安全策略——没有密码暴力破解限制、新设备自动批准——攻击者可以先让受害者的浏览器连接到本地网关，然后暴力破解密码，最后注册一个恶意设备。整个过程只需要几秒钟。

日志污染漏洞同样令人担忧。OpenClaw的代理会读取自身日志来进行故障排除，这意味着攻击者可以在日志文件中植入恶意指令。当代理读取这些日志时，这些指令就会被执行，从而实现所谓的"间接提示注入"。

2.3 数据库配置失误与Moltbook泄露

当用户将OpenClaw部署到云服务器以便远程访问时，他们可能没有意识到自己正在创建一个可能被攻击的互联网暴露面。

Moltbook数据泄露则是另一个维度的灾难。Moltbook是OpenClaw创始人发明的"AI社交网络"——一个允许AI代理发帖、评论、投票的平台。Wiz安全研究发现，这个平台使用的Supabase数据库API密钥竟然暴露在客户端JavaScript代码中。

泄露的数据包括150万个API认证令牌、35,000个电子邮件地址，以及AI代理之间的私人消息。虽然Moltbook声称拥有150万注册代理，但数据库显示背后只有17,000个真实的人类用户。

2.4 全球暴露态势数据分析

如果说前面的数据已经让你感到不安，那么来自“OpenClaw Exposure Watchboard”（官网：https://openclaw.allegro.earth/）的最新数据可能会让你重新考虑是否继续使用OpenClaw。

图11 2026年03月10日OpenClaw暴露态势的综合统计

图11展示了全球OpenClaw暴露态势的综合统计，包括：按国家/地区分布(左上)，中国占42.3%居首；凭据泄露情况(右上)，37.2%的暴露主机存在凭据泄露；威胁组织关联(左下)，40.7%的主机关联已知APT组织；TOP 8威胁组织分布(右下)，APT37和Kimsuky关联最多。

互联网测绘的数据显示了一个更为严峻的现实。针对OpenClaw开放服务的大规模扫描发现，全球共有273,548个暴露在互联网上的OpenClaw实例——这个数字远远超出了此前的估计。全球暴露主机分布 Top10：

表1 全球暴露主机分布 Top10

我国以超过11.5万的暴露主机数量位居全球首位，占总量的42.3%。美国紧随其后，有7.3万个暴露实例。这两个国家合计占据了近70%的全球暴露量。

凭据泄露情况显示在273,548个暴露主机中，有101,755个（37.2%）被发现存在凭据泄露问题。这意味着超过三分之一的暴露主机上，攻击者可以直接获取到有效的认证凭据。

与威胁组织的关联将风险提升到了一个新的层次。数据显示，有111,389个暴露主机（40.7%）与已知威胁组织存在关联。这个数字意味着，将近一半的暴露实例可能已经被国家级攻击者或网络犯罪组织所利用。威胁组织图谱覆盖了多个知名的APT组织：

表2 多个APT组织与OpenClaw暴露主机有关联

这些数据揭示了一个令人不安的事实：OpenClaw的暴露主机已经成为国家级网络攻击者的重要目标。APT37和Kimsuky这两个朝鲜APT组织关联的暴露主机数量最多——这可能与OpenClaw频繁被用于加密货币交易和金融操作有关。俄罗斯背景的APT28和Sandworm Team同样活跃，它们关联的暴露主机数量也都超过了7万个。

第三章

深度透视：为什么AI Agent如此脆弱

3.1 架构设计的原罪

要理解OpenClaw为什么会出现这么多安全问题，我们需要从它的架构设计说起。

OpenClaw的核心是一个名为"Gateway"的本地组件，它本质上是一个WebSocket服务器，负责协调AI代理与各种工具和服务之间的交互。这个设计赋予了AI代理极大的能力，但也创造了巨大的攻击面。

图12 架构风险

图12展示了OpenClaw的架构及风险点：Gateway作为WebSocket服务器与Shell、文件、邮件、社交媒体等服务连接，每个连接点都存在潜在安全风险。

本地连接的信任过度是最大的问题之一。OpenClaw的设计假设本地连接是可信的，因此对来自localhost的连接实施了多项安全放松：无密码暴力破解限制、新设备自动批准、权限提升不需要二次确认。这种设计在单机环境下可能是合理的，但在现代网络环境中却成为了致命弱点。

问题的根源在于浏览器的跨域策略。WebSocket与HTTP不同——浏览器不会阻止跨域的WebSocket连接。这意味着当你访问任何网站时，该网站上的恶意JavaScript都可以尝试连接你本地运行的OpenClaw网关。

工具执行的权限过大是另一个设计缺陷。OpenClaw可以执行任意shell命令，这意味着如果攻击者获得了代理的控制权，他们可以在你的系统上做任何事情。

3.2 输入验证的语义鸿沟

在输入验证层，OpenClaw的external-content.ts模块针对提示词注入的防御存在严重的语义感知脱节。该模块强依赖传统的词法匹配（正则表达式），试图通过关键词过滤来阻止恶意指令。然而，大语言模型（LLM）的处理逻辑是基于Token的高维语义映射，而非字面量字符串匹配。攻击者通过注入Unicode转义序列或Base64编码载荷，能够完美绕过正则引擎的静态词法分析。当这些编码后的载荷进入LLM的上下文窗口时，模型原生的解码能力会将其还原为极具破坏性的特权指令，导致思维链（Chain-of-Thought）被彻底毒化。

图13 基于词法过滤的Prompt Injection检测及其Unicode/Base64绕过分析

这种攻击方式的隐蔽性在于：传统的安全扫描工具根本无法识别Base64字符串中的恶意内容，而LLM却能完美理解并执行。

3.3 供应链的信任缺口

OpenClaw的生态系统依赖于一个看似美好的理念：开放协作。任何人都可以上传技能，任何人都可以发布NPM包，任何人都可以在GitHub上分享代码。但这种开放性在没有足够安全机制保护的情况下，也成为了攻击者的乐园。

ClawHub审核机制的缺失是最明显的问题。这个市场唯一的门槛是发布者需要拥有一个至少一周龄的GitHub账户。研究人员发现，攻击者会创建多个账户、使用相似名称进行域名仿冒、精心制作看起来完全合法的文档。

3.4 暴露面与管理真空

配置不当的普遍性令人震惊。许多用户为了使用方便，选择关闭身份验证或使用弱密码。这使得他们的OpenClaw实例变成了"软柿子"——只需要简单的扫描和最基础的暴力破解就能获得访问权限。

更新滞后加剧了问题。从漏洞被公开披露到用户实际应用修复之间，存在一个危险的时间窗口。从互联网上暴漏的数据显示，许多OpenClaw实例运行的是过时版本，这使它们成为已知漏洞的猎物。

3.5 工具链的攻击转化路径

在执行层，OpenClaw的模型上下文协议（MCP）缺乏运行时的细粒度指令拦截。一旦上述的语义毒化生效，AI代理便会由被动响应状态转变为主动攻击引擎。

图14 AI Agent 语义空间至物理环境的攻击演进图谱

从上图可以看出攻击者可通过下面两条路径完成武器化：

• SSRF攻击路径：OpenClaw内置的浏览器与网络工具包被劫持为跳板，实施服务器端请求伪造（SSRF），用于探测内网服务或窃取云环境元数据（如：AWS IMDSv1的临时凭证）。

• RCE攻击路径：本地Shell 接口将自然语言的逻辑偏差直接放大为无需提权的远程代码执行，完成从虚拟认知层到物理宿主系统的终极穿越。

CVE-2026-24763与CVE-2026-25157暴露的并非表层编程缺陷，而是AI Agent安全设计范式的根本性缺陷：以应用层防御机制对抗语义空间攻击，无异于以城墙抵御空气传播的病毒。

第四章

防御策略与最佳实践

4.1 普通用户的自我保护

如果你只是在个人电脑上运行OpenClaw，以下是你需要立即采取的行动：

图15 安全自查清单

图15展示了OpenClaw用户应遵循的5项核心安全措施：（1）立即更新版本（2）警惕可疑链接（3）仅从官方渠道安装（4）限制授权范围（5）定期检查会话状态。

立即更新到最新版本。这听起来像是老生常谈，但在OpenClaw的案例中尤为关键。研究人员披露的多个严重漏洞都已经在新版本中得到修复。运行"openclaw update"只需要几秒钟。

永远不要点击可疑链接。任何要求你访问特定网站或执行安装命令的链接都应该引起警惕。如果有人声称需要你"安装额外组件"才能使用某个功能，这几乎肯定是一个骗局。

只从官方渠道安装。OpenClaw的官方GitHub仓库是github.com/openclaw/openclaw。任何其他的"官方镜像"、第三方安装程序都可能是恶意的。

限制授权范围。定期检查你的OpenClaw集成了哪些服务，取消那些你不再使用或不需要的OAuth授权。

4.2 开发者的安全规范

如果你在开发环境中使用OpenClaw，你需要采取更严格的安全措施：

确认Gateway绑定模式。默认情况下，OpenClaw Gateway仅监听本地回环地址（127.0.0.1），这是安全的设计。可以通过以下命令确认：

openclaw config get gateway.bind 

openclaw gateway status 

输出应该显示 bind=loopback。如果显示其他值，应立即修正为：

openclaw config set gateway.bind "loopback" 

检查认证模式。官方默认使用token认证模式，可通过以下命令检查：

openclaw config get gateway.auth 

定期审计活跃会话。养成定期检查会话列表的习惯，识别任何可疑的连接：

openclaw sessions 

配置敏感命令限制。OpenClaw允许通过nodes配置限制敏感命令的执行权限，官方默认已禁止部分高风险操作：

openclaw config get gateway.nodes.denyCommands 

使用专用机器。尽量不要在日常开发机器上运行OpenClaw，使用一台隔离的专用机器来运行这个AI助手。

隔离配置存储。配置文件位于~/.openclaw/openclaw.json，其中包含敏感凭据信息，应妥善保管。

4.3 企业级部署指南

企业落地OpenClaw，核心不是“把服务跑起来”，而是先把风险关进边界。建议按“网络分区、强认证、集中审计、分钟级响应”四条主线建设，先达成最小可用安全基线，再逐步扩展能力。

第一，先做网络与暴露面收敛。

生产环境采用DMZ/应用区/管理区三层分区：DMZ只放反向代理或WAF，应用区部署Gateway/Agent，管理区承载堡垒机、日志与密钥系统。云上建议使用VPC + 私有子网，默认拒绝入站，仅放行必要端口；OpenClaw节点不分配公网IP。Gateway仅绑定loopback或内网地址，远程运维统一经VPN或ZTNA。每月做一次外网暴露面扫描，并与资产台账交叉核对，发现暴露实例立即下线整改。

第二，身份和权限优先于连接便利。

管理面接入应统一走企业IdP（SAML/OIDC）并强制MFA，经堡垒机进入；禁止共享账号，高权限操作必须可追溯到个人。系统间通信使用短TTL token或mTLS，凭据统一托管在Secret Manager（Vault/KMS），禁止明文写入脚本、镜像和仓库。权限模型以RBAC为基础，遵循默认拒绝与最小授权：命令执行、文件读写、外联能力按工单临时放权，到期自动回收；Shell执行、敏感目录访问、外发API调用等高风险动作启用二次审批。

第三，把审计能力前置到上线前。

至少采集四类日志：网关访问、执行审计、文件访问、网络连接。日志统一汇聚到SIEM，避免仅本地留存。留存周期建议：通用审计日志不少于180天，关键操作日志保留1年；同时启用对象锁/WORM/签名校验，防止痕迹被篡改。告警规则可先从最小集合起步：异常来源访问、短时高频认证失败、异常并发会话、高危命令模式、敏感目录访问、非白名单外联。

第四，按“泄露已发生”假设保护数据。

对可访问数据做分级（公开/内部/敏感/受限），默认仅开放公开与内部数据；生产数据优先提供脱敏副本或最小字段视图。传输层强制TLS 1.2+，内部服务优先mTLS；日志、会话、缓存启用加密存储，密钥交由KMS/HSM托管。对邮件、IM、Webhook、外部API等出口部署DLP，拦截凭据和敏感标识；同时持续进行repo、镜像、日志秘密扫描，命中即触发凭据轮换。

第五，事件响应要可在分钟级执行。

触发条件建议明确为四类：异常会话、可疑命令、敏感数据异常访问、未授权外联。处置节奏可固定为：15分钟内隔离节点并吊销凭据，4小时内完成入口与影响范围研判并下发IOC，24小时内完成配置修补与回归验证，48小时内提交复盘并沉淀检测规则到SIEM/SOAR。

这套方案与OpenClaw官方“本地监听、默认认证、最小暴露面”的原则一致，也与企业零信任、最小权限、分层防御的通用实践对齐。

4.4 面向未来的安全思考

OpenClaw的安全危机预示着整个AI Agent行业都将面临类似的安全挑战。

权限与功能的永恒矛盾将持续存在。AI代理需要足够的权限才能发挥作用，但每增加一项权限就可能创造一个新的攻击面。

供应链安全必须得到根本性重视。我们需要更好的机制来验证和审核第三方组件。

零信任架构应该是最终目标。在零信任模型下，每个请求——无论来自哪里——都需要被验证。

第五章

结 论

OpenClaw从GitHub历史上增长最快的开源项目，到成为安全危机的焦点，只用了短短几周时间。这并非偶然而是AI Agent安全范式转变带来的系统性风险的集中体现。

当AI被赋予"上帝模式"的权限时，它就成为了一个极具吸引力的攻击目标。攻击者只需要诱骗用户点击一个链接，或者上传一个看似无害的插件，就能获得对受害者系统的全面控制。

但危机中也蕴含着机遇。OpenClaw暴露出的问题正在推动整个行业重新思考AI Agent的安全设计。

对于已经使用或计划使用OpenClaw的用户，我们的建议很简单：不要恐慌，但也不要掉以轻心。采取基本的防护措施——更新到最新版本、限制暴露面、警惕可疑链接——可以有效地将风险降到可接受的水平。

最后，保持关注。这个领域的快速发展意味着新的威胁和新的防护措施都在不断涌现。

参考链接：

[1]https://mp.weixin.qq.com/s/r_s14u2I4Nyr8Yv5KI25tw

[2]https://www.infosecurity-magazine.com/news/researchers-40000-exposed-openclaw/

声明：本文来自ADLab，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。