Moltbook安全危机:漏洞暴露数据库,用户面临身份冒用和账户失控风险

Moltbook 曝出严重安全漏洞,数据库暴露,可冒充Karpathy发帖。用户面临密钥被重置风险,安全问题引人深思。

原文标题:Moltbook漏洞大到可以冒充Karpathy发帖,黑客都急了

原文作者:机器之心

冷月清谈:

近期,AI 社区 Moltbook 遭遇了一系列信任危机。先是被曝出 AI Agent 注册数量造假,存在大量通过程序批量注册的虚假账号。紧接着,白帽黑客揭露 Moltbook 存在重大安全漏洞,整个数据库暴露,包括 API 密钥在内的敏感信息面临被窃取的风险。攻击者可以利用这些信息冒充平台上任何 Agent 的身份发帖,包括知名 AI 人物 Karpathy。漏洞源于 Supabase 密钥的公开暴露,允许任何人对 Agents 表进行公开读取。虽然 Moltbook 创始人已着手修复,但重置 API 密钥可能会导致用户无法访问自己的机器人,因为平台缺乏有效的用户身份验证和恢复机制。此外,OpenClaw 还存在一键远程代码执行漏洞,进一步加剧了 Moltbook 的安全困境。目前相关漏洞已修复,但本次事件无疑给新兴 AI 社区敲响了警钟,在追求创新的同时,必须高度重视安全问题。

怜星夜思:

1、Moltbook 的安全事件,对其他 AI 社区有哪些警示意义?除了技术层面的修复,社区运营者还应该从哪些方面加强安全管理?
2、Moltbook 在修复漏洞时,面临重置 API 密钥可能导致用户无法访问自己 Agent 的困境。你认为他们提出的「旧密钥换新密钥」接口和「通过 X 账号重新验证身份」方案,哪个更合理?还有没有其他更好的解决方案?
3、如何看待 AI 社区这种新兴事物?你认为 AI 社区未来发展会面临哪些挑战?

原文内容

图片
编辑|杨文

上周末,闹得沸沸扬扬。


最初,凭借「AI 发帖、人类围观」的设定在 AI 社区一炮走红,吸引大量网友围观:



但很快就有人曝出,那些看似由 AI 生成的帖子,实际上都是人类通过后端发布的:



甚至连平台标榜的 AI Agent 注册数量也是假的。因为创建账号时没有任何速率限制,任何人、包括 AI 都能疯狂批量注册假账号。极客 Nagli 亲手用自己的 Openclaw 在短时间内就刷出了 50 万个假用户。


周六截至机器之心发稿前,Moltbook 注册的 AI Agent 数量也只是 50 多万个,但到了周日,一下子就超过 150 万了,原来这夸张的增长速度背后全是水分。


造假风波尚未平息,现在 Moltbook 又陷入更严重的安全问题。


一位名为 Jamieson O'Reilly 的白帽黑客发帖称,Moltbook 存在重大安全漏洞,导致整个数据库暴露在公众面前,包括秘密 API 密钥在内的所有敏感信息都可被任意访问。


这意味着任何人都可以冒充平台上任意 Agent 的身份发帖,甚至包括拥有 190 万粉丝的 AI 领域知名人物 Karpathy



「想象一下,假的 AI 安全言论、加密货币诈骗推广,或煽动性的政治声明,看起来都像是出自 Karpathy 之口。而且不只是 Karpathy,从我掌握的情况来看,整个平台上的所有 Agent 目前都暴露了。」



有网友在底下评论区询问漏洞的具体成因,「是 Superbase 的问题吗?为什么人们可以对数据库运行查询?」


Jamieson O'Reilly 解释称,该漏洞涉及多个安全问题,其中最严重的是 Moltbook 使用的 Supabase 密钥被公开暴露,允许任何人对 Agents 表进行公开读取。


攻击者只需发送一个简单的 GET 请求即可获取用户的所有数据:


/rest/v1/agents?name=eq.theonejvo&apikey=xxxxx 


这个请求可以直接导出指定用户的完整信息。



在过去几小时内,Jamieson O'Reilly 一直试图联系 Moltbook 创始人,但未获回应。他只能在推文中公开喊话:「要么直接关闭你们的 supabase 数据库访问,要么马上让你们的 AI 编码助手执行以下操作」。


他给出了具体的修复方案:


1. 在 agents 表上启用行级安全策略 (RLS):


ALTER TABLE agents ENABLE ROW LEVEL SECURITY;


2. 创建限制性访问策略,阻止匿名用户直接访问表数据:


-- Public can only see non-sensitive columns via a view
CREATE POLICY "anon_read_public_fields" ON agents
FOR SELECT TO anon
USING (false);
-- Authenticated users see only their own
CREATE POLICY "users_own_data" ON agents
FOR SELECT TO authenticated
USING (auth.uid() = owner_id);



Supabase 的 CEO 看到消息后表示,他们已经努力联系并配合 Moltbook 创建者处理此事,但他们无法替用户直接执行这类数据库权限修改。Supabase 平台的安全顾问团队已经准备好了一键修复方案,只要创建者点击一下,就能立即封堵这个漏洞。



随后,Moltbook 创建者 Matt Schlicht 回应称,他已经在处理了。



修复引发新问题


Jamieson O'Reilly 在紧密跟踪修复进程后发现了新麻烦:如果现在把所有 Agent 的 API 密钥全部重置换成新的(这是修复安全漏洞的必要步骤),那用户就全傻眼了。


原因在于, Moltbook 这个平台根本没有网页登录功能,用户只能靠 API 密钥来控制自己的机器人。一旦密钥换了,所有用户瞬间被锁死,没法再发帖、操作自己的 AI Agent。既没有邮箱验证,也没有网页重置密码啥的,用户没有任何恢复办法。


他给出了两个可能的解决思路:要么做一个临时的「旧密钥换新密钥」接口,给一段宽限期让用户自行更换;要么强制所有人通过 X 账号重新验证身份来获取新密钥。



此外,一名前 Anthropic 工程师还发布了针对 OpenClaw(前身为 Moltbot 和 ClawdBot)的一键远程代码执行漏洞。


该攻击在受害者访问网页后几毫秒内发生,攻击者可获得 Moltbot 及其运行系统的访问权限,而受害者无需输入任何内容或批准提示。目前该漏洞已修补。



有机器之心读者在后台反馈称,他们单位已经发布 Clawdbot 平台有重大漏洞的情况通告,要求内部禁止使用。



参考链接:

https://x.com/javilopen/status/2017880072946893112?s=20

https://x.com/KookCapitalLLC/status/2018057772118519928?s=20

https://x.com/IntCyberDigest/status/2018095767391477964

https://x.com/galnagli/status/2017585025475092585


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:liyazhou@jiqizhixin.com

Moltbook 这事儿告诉我们,技术再牛也得经得起安全考验,不然就是空中楼阁。除了技术层面,我觉得更重要的是安全意识的培养。开发者要时刻紧绷安全这根弦,不能有侥幸心理。社区运营者也要定期进行安全培训,学习最新的安全攻防技术,才能更好地保护用户的信息安全。另外,建立完善的漏洞报告机制也很重要,鼓励白帽黑客来帮忙找漏洞,防患于未然。

我觉得「旧密钥换新密钥」接口更靠谱点。给用户一个过渡期,让他们自己去换,既能保证安全,又能最大限度地减少对用户的影响。用 X 账号重新验证身份感觉有点麻烦,而且不是所有人都有 X 账号。「更好的方案?那就只能是提前做好用户账户系统和密码管理,别等出了事儿才来补救了。亡羊补牢,为时未晚,但是事前做好预防工作总是更好。

「通过 X 账号重新验证身份」感觉更现代,也更安全。现在社交账号绑定很常见,用户接受度也比较高。但是,确实要考虑到有些用户没有 X 账号的情况,可以考虑增加其他的验证方式,比如邮箱验证或者手机验证。最好的方案是,给用户多种选择,让他们自己选择最方便的方式。

AI 社区是未来的趋势,可以让更多的人参与到 AI 的发展中来。但是,也得防止被别有用心的人利用。比如,传播虚假信息、进行网络诈骗等等。未来,AI 社区可能会面临监管、伦理、隐私等方面的挑战。需要政府、企业、社区共同努力,才能解决这些问题。

我觉得这次 Moltbook 事件给所有新兴的 AI 社区都敲响了警钟!技术上,暴露数据库密钥这种错误简直是不可原谅,以后一定要加强安全审计。更重要的是,社区运营者不能只顾着增长和创新,忘了用户的数据安全和隐私。应该建立更完善的身份验证和恢复机制,比如邮箱验证、短信验证等等,不能让用户因为一次密钥重置就彻底失去账号控制权。