超过4万个OpenClaw实例毫无防护地暴露在公网上，其中60%以上可直接被远程接管。当一个开源智能体工具的扩散速度远超安全监管与用户教育的速度时，最终的责任与风险将由谁来承担？
2026年3月10日，珠海科技学院发布了一则措辞严厉的通知：严禁全校教职工在任何办公设备、教学终端及校园网络环境下安装、运行或使用OpenClaw软件本体、其衍生版本、配套插件及任何第三方技能脚本。这里使用的是“严禁”，而非“建议”。
同一周内，山西应用科技学院也要求已安装OpenClaw的人员必须在3月15日前完成彻底卸载，包括清除所有相关配置、缓存及日志文件。安徽师范大学、江苏师范大学等高校也相继发出了类似的安全警示。
3月11日，国家工信部网络安全威胁和漏洞信息共享平台发布了一份正式文件：《关于防范OpenClaw开源智能体安全风险的“六要六不要”建议》。几乎同期，国资委也向国有企业下发通知，要求限制乃至禁止OpenClaw在政府机关和国企敏感环境中的部署。
令人深思的是，仅仅在一个月前，OpenClaw还是全民热议的“效率神器”。腾讯总部曾有上千员工排队体验，百度更是将其集成到了日活超7亿的App中。而一个月后，剧情急转直下：高校要求卸载，金融机构内部禁用，国家部委亲自出面发布风险提示。
这个转折发生的速度，与OpenClaw自身病毒式扩散的速度几乎一样快。
OpenClaw的安全暴露面
- 40,000+ — 暴露在公网上的OpenClaw实例数量
- 60%+ — 可被攻击者直接接管的比例
- 1,000+ — ClawHub技能市场上已被标记的恶意skill数量
安全研究人员在3月初进行了一次全网扫描，结果触目惊心：超过4万个OpenClaw实例直接暴露在公共互联网上，且未配置任何有效的访问控制措施。其中，60%以上的实例存在已知漏洞，攻击者可以远程接管控制权。
“可以被远程接管”意味着什么？这意味着攻击者能够完全控制这些智能体的行为——读取该智能体被授权访问的所有数据（如邮件、网盘）、以该智能体的身份执行任意操作（如发送消息、调用API），甚至修改其核心指令，将其转变为长期潜伏的后门。
安全公司将OpenClaw的风险模型归纳为 “致命三角” ：私人数据的高权限访问、与外部环境的通信能力、暴露于不可信的输入内容（如第三方技能）。这三者同时存在时，任意一个环节被突破都可能引发灾难性的连锁反应。
一个被劫持的智能体可以悄然读取你的私人邮件、访问公司云盘上的敏感文件、调用你已授权的所有付费API——而你很可能对此毫不知情，因为它表面上仍在“正常”工作，完美地隐藏了恶意行为。这种对安全模型的漠视，是当前许多AI应用面临的共同挑战。
解读工信部的“六要六不要”
工信部发布的这份指南，每一条都直指当前最普遍的安全痛点：
- “要使用官方最新版本” —— 这条建议背后是一个严峻的事实：大量用户并非从官方渠道下载，而是使用了第三方镜像站提供的安装包。这些安装包看似与官方版无异，但可能内置了额外的数据回传模块，悄无声息地窃取信息。
- “要严格控制互联网暴露面” —— 这条直接指向那4万个“裸奔”的实例。许多用户为了调试方便，在配置时打开了远程访问端口（如Web UI的管理端口），事后却忘记关闭，将内部工具彻底暴露给了整个互联网。
- “要坚持最小权限原则” —— 这条触及了OpenClaw乃至所有效率工具的根本设计矛盾。智能体要有用，就需要被授予权限。权限越多，能力越强，用户体验越“爽”。但权限越多，一旦被攻破，造成的破坏也越大。“最小权限”在理论上是安全铁律，但在实际使用中，大多数用户的选择往往是图方便的“全选授予”。
- “要谨慎使用skill市场的第三方产品” —— ClawHub上已有超过15万个由社区开发的技能（skill），其中超过1000个已被安全团队标记为恶意。然而，ClawHub缺乏类似苹果App Store的严格审核机制。一个开发者上传一个恶意skill，几分钟后就能被全球用户下载安装，其传播和危害速度远超传统软件。
“六要六不要”核心条目摘要：
- 要 —— 使用官方最新版本（防范篡改安装包）
- 要 —— 控制互联网暴露面（及时关闭调试端口）
- 要 —— 坚持最小权限原则（仅授予必要权限）
- 要 —— 谨慎使用第三方skill（防范恶意技能）
- 不要 —— 使用来源不明的第三方镜像
- 不要 —— 在敏感网络环境中部署未经安全审计的智能体
每一条建议都正确且必要。但它们共同面对的是一个更深层的结构性矛盾：OpenClaw是开源的。
开源意味着任何人都可以自由下载、修改、分叉和分发。工信部可以建议用户使用官方版本，但无法阻止无数第三方镜像站的存在。高校可以要求学生卸载校园网内的软件，但无法确认学生个人设备上是否仍在运行。银行可以禁止在办公电脑安装，却难以管控员工使用手机上的OpenClaw处理工作事务。
这并非OpenClaw独有的困境。Linux, Docker, Python —— 所有成功的开源项目都经历过“使用者规模远超维护者管控能力”的阶段。但OpenClaw与这些工具有一个本质区别：Linux主要管理系统资源，Docker管理容器环境，而OpenClaw处理的则是 用户的数字身份 及其背后的完整权限链。
一个配置不当的Linux服务器至多泄露该服务器上的文件。一个配置不当的OpenClaw智能体，泄露的将是用户授予它的、对所有关联服务（邮箱、网银、社交账号、企业办公系统）的访问权限，危害呈指数级放大。
“开源软件的安全模型建立在一个前提上：用户有能力评估和管理风险。但OpenClaw的用户画像已经从极客开发者扩展到了普通消费者——他们大多不具备这种能力。” —— 安全内参评论
出圈的代价与缺失的“防火隔离带”
OpenClaw当前安全危机的根源，恰恰在于其过于成功的“出圈”。
当它仅在开发者社区内流行时，安全问题尚可通过社区自治解决。开发者懂得如何配置防火墙、理解“最小权限”原则的重要性、并习惯从官方渠道获取软件。
然而，当百度通过DuClaw将其推向7亿日活用户，当飞书、钉钉将其深度集成进企业协作流程，当腾讯组织上千人排队体验时，OpenClaw的用户基数便从数万开发者暴增至数千万乃至上亿的普通用户。
普通用户不会主动阅读安全公告，不了解端口暴露的风险，更难以理解“最小权限”的深刻含义。他们只感受到工具带来的便利——智能体可以自动回复邮件、整理周报、安排会议。
于是，4万个智能体在公网上“裸奔” 成了必然结果。
工信部的“六要六不要”是一份面向技术人员的安全指南，高校的禁令是一道行政命令。但OpenClaw暴露的安全风险，既无法单靠指南教育所有用户，也无法靠一纸禁令彻底根除。它需要的是在框架层面进行安全重构：默认关闭远程访问、强制实施权限最小化设计、为技能市场引入必要的审核机制。
这些改动需要OpenClaw核心开发团队来主导。但据报道，其核心团队不足20人，且主要精力仍集中于功能迭代，而非基础安全加固。这种“功能先行，安全后补”的开发模式，在用户量爆炸式增长后，留下了巨大的安全债务。
这让人联想到1906年的旧金山大地震。事后调查发现，火灾席卷全城的主要原因并非地震本身的破坏力，而是城市在狂热扩张中，完全忽略了防火隔离带的建设。建筑越盖越快、越盖越密，但关键的消防基础设施却远远落后。
如今，OpenClaw那4万个暴露在公网上的实例，就像是这座数字城市里缺失的“防火隔离带”。如果只顾狂奔，无视安全基建，那么发展的速度并不会因为缺少隔离带而放缓——它只会让下一场“大火”烧得更快、更旺。对于关注此类运维与安全平衡实践的开发者，可以前往云栈社区的相应板块，与更多同行交流基础设施安全与稳定性保障的经验。
发表于 3 小时前
|
查看: 3|
回复: 0
