Clawdbot五天狂飙10万Star！但权限失控、数据裸奔与安全漏洞的风暴正在酝酿

智猩猩AI整理

编辑：汐汐

在开源世界里，GitHub上的Stars数量往往像一面镜子，映照出技术的热度与社区的脉动。当一个项目突破10万Stars时，它通常被视为时代的注脚。

2026 年初，Moltbot（曾用名Clawdbot）就是这样一个现象级故事：它从开发者 Peter Steinberger 的个人实验起步，旨在打造一个“能主动找你聊天”的 AI 伙伴，却意外点燃了全球对“自治AI Agent”的狂热，短短几天便攀上了这一流量巅峰。

然而，这并非一个单纯的技术童话。

当人们沉浸在AI从“工具”向“伙伴”转变的兴奋中时，很少有人注意到，这种“主动性”与“开放性”的背面，正敞开着一道通往用户隐私腹地的后门。 随着项目病毒式传播，一场关于权限失控、数据裸奔与架构漏洞的风暴正在酝酿。

这10万Stars的背后，不仅是开发者的狂欢，更是一身冷汗。

01 退休三年卷土重来：三天就改名、72小时一地鸡毛

Clawdbot的Star数暴涨过程像一部紧凑的科技剧：这个开源AI助手在2026年初突然爆红，GitHub上短时间积累了数万Stars，成为最受关注的开源项目之一。

随后，创作者因Anthropic对“Clawd”名称与其Claude商标的侵权可能性的逼迫，将Clawdbot改名为Clawdbot，但在账号迁移时出现了旧账号被抢注的混乱。更名期间，一些人利用旧品牌热度推销假冒加密货币，并造成了投资者损失，但官方项目并未推出任何代币，并反复提醒社区警惕骗局。这暴露了开源项目的脆弱性，却也间接证明了其影响力。

作为创始人，Peter Steinberger曾发帖透露出他对项目的朴实愿景。他观察到，传统AI助手太被动，“像在等你命令”，而Clawdbot强调“主动性”——它能通过WhatsApp、Telegram、Discord等渠道自动执行任务并向你发送提醒。Steinberger在一次回复用户时提到记忆管理的重要性：“如果想让它永远记住某些事，就提示它更新agents文件”

Steinberger的观点并非高屋建瓴，而是基于他多年软件开发经验和对个人自动化工具的理解。他在退休三年后，于2025年重新投入开发，将Moltbot视为“数字生活管理者”，这也解释了为什么项目从一开始就注重跨平台集成和本地运行，以避免对云端的过度依赖。

02 10万stars狂欢背后：安全、数据和隐私问题何解

Moltbot能在短时间内突破10万Stars，并非偶然。

观察社区的讨论，许多开发者指出，它填补了AI Agent领域的空白，不像封闭的ChatGPT，Moltbot开源且可自托管，满足了人们对“AI真正做事”的期待。并且还得益于传播效应，项目文档简洁清晰、安装支持多平台且对技术爱好者极具吸引力，加之社区贡献的“技能扩展”，迅速促进了生态活跃度与关注度的提升。

但是，代价是什么？争议与隐忧同样不可忽视，这并非空穴来风，而是有迹可循、有踪可觅。

安全研究员Osama在花费了整整两天的时间测试研究后曝光，“测试常见自托管设置，发现多个关键漏洞，很容易在真实使用中触发”。

因为这个项目迅速走红，用户量大，但是很多用户在了解他是否能安全做些什么之前就将其部署上去，这导致其存在非常严重的安全风险。

他强调有1009个Clawdbot网关暴露在公共互联网上，并且数百个没有身份验证，这些能够通过Shodan搜索立即发现。这可能会导致API密钥完全暴露、私人聊天历史泄露，并且会容易导致身份劫持，甚至远程运行root级命令。

同时，通过如下命令能做到本地主机漏洞攻击：

javascript >>>

if (socket.remoteAddress === '127.0.0.1') {

  return autoApprove();  // FATAL FLAW

}

其根本原因是其默认配置gateway.trustedProxies = []存在重大风险， X-Forwarded-For头部被忽略，这会导致通过代理的所有流量看起来都是本地的，身份验证完全被绕过去。

因此存在严重的数据劫持奉献，通过本地主机漏洞，能轻松获取凭证于密钥、聊天记录、用户系统配置，甚至能让攻击者直接冒充用户。

这让攻击者几乎能完全身份接管、无限期持久访问并且几乎0%的检测风险！

所以这其中存在一些安全悖论，是让AI访问一切，还是让它隔离起来；是让AI具备长期记忆持久状态，还是用沙箱分隔开来；让AI自主行动，还是用人工来审批控制；让AI具备跨平台的统一访问身份，还是建立安全分层的信任边界？

这些是基本的架构选择，一旦这被攻破，就会让AI变得非常灾难性。

那么解决办法和预防措施是什么呢？Osama也给出了他的答案。

1、执行全面安全审计命令

运行 clawdbot security audit --deep 对当前系统配置、网络暴露面、访问控制策略和权限设置进行深度检查，以发现潜在的错误配置和安全隐患。该命令可识别网关鉴权暴露、工具权限范围过宽、文件系统权限不当等常见高风险项，是部署后和配置更改后必须执行的安全步骤之一。

2、利用指纹搜索服务检查公网暴露实例

使用Shodan、Censys等互联网服务指纹索引平台检索Clawdbot控制UI或网关指纹，以确认是否有实例错误暴露于互联网。

3、轮换所有凭证并启用强制身份验证

对于所有敏感凭据（如网关认证令牌、模型 API 密钥、通信渠道令牌等）进行重新生成和更换，以清除可能已泄露的凭据；同时应启用网关的强制身份验证机制（如 token 或密码认证）。

4、正确配置可信代理

在通过反向代理（如nginx、Caddy、Traefik）或负载均衡器部署时，明确设置gateway.trustedProxies，指定受信任的代理IP。这样Clawdbot 的网关才能正确识别并处理X-Forwarded-For等头部信息，避免外部流量通过伪造头部冒充本地连接，绕过身份认证逻辑。

5、通过安全隧道服务暴露接口

采用如Tailscale Serve、Cloudflare Tunnel等加密隧道技术替代直接的公网端口开放，实现“零信任”访问控制和加密传输，降低系统暴露面。

同时为了安全起见，建议采取如下预防措施：

1、不要将 Gateway 直接暴露于公网

请确保Clawdbot的Gateway仅绑定在 本地回环地址（localhost） 或受控网络中运行，不要直接监听公网IP，如0.0.0.0。如果需要远程访问，请使用安全隧道（如Tailscale Serve或Cloudflare Tunnel）或VPN，而非直接公开端口。

2、在隔离环境（容器或沙箱）中运行 Clawdbot 实例

推荐将Clawdbot部署在受限的Docker容器或独立虚拟机中，限制其文件系统、网络访问权限和系统调用。官方文档建议利用per-session sandbox或容器技术将代理工具与宿主系统隔离，以降低越权访问风险。

3、实施严格的设备配对与访问控制策略

使用Clawdbot内置的DM配对机制和访问策略（如allowlists、groupPolicy限制等），确保只有经过批准的客户端或设备才能向 AI 代理发送消息或触发操作。

4、持续监控与日志审计以检测异常行为

对 Gateway 和代理交互进行持续监测，包含检查会话日志、验证配置变更以及监测异常请求模式。安全审计工具（如clawdbot security audit）可定期检测错误配置、权限过宽漏洞及其他高风险设置。

5、将 Clawdbot视为特权组件并强化访问保护

Clawdbot能执行如读取/写入文件、调用shell命令等高权限操作，因此应将其视为特权组件，设置强身份认证机制（如token或密码认证）并避免任何默认弱口令或无认证访问。即使在受信网络中，也应对凭据进行周期性轮换并限制持久凭据的权限范围。

03 半“裸奔”的AI遇上国内互联网：普通用户应该如何选择？

Clawdbot在全球爆火的同时，迅速“登陆”中文互联网，国内各大云厂商几乎在同一天“抢跑”接入。

2026年1月28日，腾讯云率先上线轻量应用服务器Lighthouse的一键部署模板，用户选购实例、勾选“Moltbot”应用镜像，几分钟内即可完成安装；阿里云紧随其后，不仅推出轻量应用服务器镜像，还通过无影云电脑提供预装套餐，甚至打通钉钉、飞书、企业微信、QQ等本土IM通道，实现“国内版AI管家”无缝落地；优刻得、华为云等玩家也纷纷跟进，提供海外节点（如新加坡、香港）低至68元/年的入门配置，免备案、稳定在线、7×24小时运行，成为许多用户抛弃本地Mac Mini或闲置PC的首选。

诚然，如Bitdefender、SlowMist和SOC Prime等多家安全公司已确认，尤其在企业云环境中，暴露的控制面板和凭证泄露是真实威胁。

但是在国内互联网的现实条件下，对大多数普通用户而言，云部署并非“更危险”的选择，反而可能是更理性的安全折中方案。相较于个人本地设备长期在线、网络环境复杂、缺乏系统化防护，主流云服务商在网络隔离、安全组、防火墙、日志审计等基础设施层面已形成成熟体系，为高权限AI Agent提供了更标准化的运行边界。云端并不会自动消灭风险，但它至少把“安全”从完全依赖个人经验，转移到可配置、可审计、可回滚的工程体系中。真正的问题不在“是否上云”，而在于用户是否意识到，当AI从工具进化为执行者，部署方式本身，就已经是安全架构的一部分。

Clawdbot的迅速落地与云端部署的普及，只是人类进入智能体时代的前奏。