Moltbook 数据库裸奔：475 万条记录、150 万 API 令牌，AI 写的代码忘了开 RLS

2026 年初，仅供 AI 智能体「闲逛」的论坛 Moltbook 因后端配置失误，被谷歌旗下网络安全公司 Wiz 发现大规模数据库暴露。据蓝点网报道，泄露规模远超「几张表走光」：约 475 万条记录、约 150 万个 API 授权令牌、超过 3.5 万个属于人类的电子邮件地址、约 2.9 万个早期注册的电子邮件地址，以及私信中出现的明文 OpenAI API 密钥。

这件事之所以刺眼，不只是因为数字大，而是因为它几乎把「AI 生成代码 + 云后端默认配置」的风险写进了教科书：产品可以一夜爆火，安全基线却可以整段缺失。蓝点网原文点出：Moltbook 本身完全依赖人工智能编码实现，作为人类控制者，可能需要仔细审阅代码。

一、背景：Moltbook 是什么，为什么会这么火

1.1 产品定位

如果你关注人工智能，并且经常刷 X/Twitter 或 Reddit，大概率听过 Moltbook。据蓝点网介绍，这是一个仅供 AI 智能体闲逛和聊天的论坛：人类只能查看内容，不能发帖和回复。

这种设定在 2026 年初的 AI Agent 热潮中极具话题性——论坛上的「居民」不是人类用户，而是各类自主智能体，它们发帖、互动、甚至彼此私信。

1.2 与 OpenClaw 生态的联动

Moltbook 非常火爆，以至于大量部署 OpenClaw（曾用名 ClawdBot / MoltBot）的用户，纷纷把自己的 AI 智能体连接到 Moltbook 上。

蓝点网指出：这种「让 AI 自己做主」的玩法很吸睛，但也把安全边界推到了人类视线之外——智能体之间能交流、能发私信、能持有令牌，一旦后端权限模型写错，冒充与窃密几乎零门槛。

1.3 技术栈：Supabase 作为后端即服务

Moltbook 依赖名为 Supabase 的后端即服务（BaaS）。Supabase 提供 PostgreSQL 数据库、认证、实时订阅等能力，是近年来 AI 辅助开发场景里极常见的选型——开发者（或 AI）可以快速搭出 CRUD，但权限策略需要单独配置。

二、事件概览：不是「黑客攻破」，是「数据库没锁门」

Wiz 的渗透路径并不玄乎。蓝点网转述 Wiz 分析报告的关键事实是：

Moltbook 客户端 JavaScript 脚本中直接暴露了 Supabase API 密钥。
在 Supabase 的设计里，公开 anon key 本身不一定致命——前提是正确启用 RLS（Row Level Security，行级安全）。
Moltbook 完全忽略 RLS 安全性，因此造成严重后果。
研究人员通过简单的漏洞即可渗透 Moltbook。
研究人员利用 GraphQL 绘制出完整的数据库模式（schema），进而发现其中的各种数据。
任何人都可以利用这些令牌冒充任何 AI 智能体。

换句话说：这不是复杂 0day，而是云产品最经典的配置事故——把「前端可见的 key」当成了「数据也可以公开」。

三、攻击链还原（据 Wiz / 蓝点网）

[1] 访问 Moltbook 客户端 JS
      ↓ 提取 Supabase API 密钥（明文可见）
[2] 以匿名客户端身份连接 Supabase
      ↓ RLS 未启用 → 策略层形同虚设
[3] 利用 GraphQL 内省 / 查询
      ↓ 绘制完整数据库 schema
[4] 批量读取数据表
      ↓ 475 万条记录、150 万 API 令牌、邮箱、私信等
[5] 利用窃取的 API 授权令牌
      ↓ 冒充任意 AI 智能体身份
[6] 读取智能体私信
      ↓ 发现明文 OpenAI API 密钥

3.1 为什么「key 在前端」有时是正常的

Supabase / Firebase 一类 BaaS 常见模式是：浏览器端使用公开的 anon key，真正的隔离靠服务端策略（RLS、Security Rules）。官方文档通常会强调：公开 key 安全的前提，是策略正确。

3.2 Moltbook 做错了哪一步

蓝点网明确写道：Moltbook 完全忽略 RLS。结果是：

攻击者能枚举 / 读取本不该对匿名客户端开放的表；
GraphQL 成为「自动画 ER 图」的工具；
令牌一旦可读，身份冒充成本接近零。

3.3 读写两条线都出过问题

时间线显示，团队先修了部分表的读取暴露，随后又发现 POST 写入访问也可被滥用——说明事故不只是「读太多」，还有一段时间处在「可被改写」的危险态。对论坛类产品，写入滥用意味着内容污染、权限提升、甚至进一步社工。

四、泄露清单与影响面（据 Wiz / 蓝点网）

类别	规模 / 说明	影响
各类数据记录	约 475 万条	大规模个人信息与业务数据暴露
API 授权令牌	约 150 万个	可冒充对应 AI 智能体
属于人类的电子邮件地址	超过 3.5 万个	钓鱼、社工、二次攻击
早期注册的电子邮件地址	约 2.9 万个	同上
AI 智能体之间的私信	4060 条	含明文 OpenAI 密钥
OpenAI API 密钥	私信中出现部分明文	可直接使用，产生账单与能力滥用

4.1 智能体私信：最隐蔽的泄密通道

Moltbook 允许 AI 智能体之间相互交流，包括发私信。Wiz 在 4060 条私信里发现部分 OpenAI API 密钥，这些密钥都是明文的，可以直接拿来使用。

这意味着泄露面从「论坛账号」扩大到「可直接消耗的第三方云账单与能力」——攻击者不需要再社工开发者，私信里就有钥匙。

4.2 身份冒充的连锁反应

任何人都可以利用窃取的 API 授权令牌冒充任何 AI 智能体。对依赖智能体身份做授权、计费或联动的下游系统，这可能触发：

伪造智能体行为与内容；
以合法身份调用关联 API；
污染论坛生态与外部集成。

4.3 事故的真实成本不只在「修表」

修 RLS 可能只要几小时；但事故成本通常在后面：

150 万级令牌意味着大规模轮换、会话失效、用户投诉；
邮箱泄露带来钓鱼与二次社工；
明文云密钥可能直接产生账单与数据外流；
品牌信任——「AI 写的社区」本就敏感，安全事故会被放大解读。

蓝点网强调修复很快，但行业读者更应记住：能被「简单漏洞」读到的窗口，对自动化扫描器来说已经足够长。

五、修复时间线（UTC，蓝点网转述 Wiz）

从发现到「全表加固」几乎在一夜之间完成，速度值得肯定；但窗口期已经存在过。

时间（UTC）	进展
2026-01-31 21:48	Wiz 通过 X/Twitter 私信功能首次与 Moltbook 开发者取得联系
2026-01-31 22:06	报告称 Supabase RLS 配置错误，导致数据库部分数据表暴露
2026-01-31 23:29	首次修复：`agents`、`owners`、`site_admins` 表已加固
2026-02-01 00:13	第二次修复：`agent_messages`、`notifications`、`votes`、`followers` 已安全保护
2026-02-01 00:31	发现 POST 写入访问漏洞（可修改所有 POST 请求）
2026-02-01 00:44	第三次修复：写入访问被阻止
2026-02-01 00:50	发现其他暴露的表：`observers`（29K 个电子邮件地址）、`identity_verifications`、`developer_apps`
2026-02-01 01:00	最终修复：所有表均已安全，漏洞已完全修复

5.1 时间线里的两个教训

第一，observers 等表是在「以为差不多修好了」之后才被发现的——说明事故响应里必须做全库枚举复测，而不是修完第一批表就收工。

第二，读写两侧要分开测：先修读、再发现写，说明「只测 SELECT」不够，POST / INSERT / UPDATE 同样要纳入验收。

六、技术细节：Supabase RLS 与 GraphQL 暴露

6.1 RLS 是什么，为什么被忽略会致命

Row Level Security 是 PostgreSQL 的行级访问控制机制。在 Supabase 架构中，浏览器端持有 anon key 是常见模式；数据库通过 RLS 策略决定「这个 key 能读哪些行、写哪些行」。

Moltbook 完全忽略 RLS，等价于：anon key 持有者可以访问策略本应拒绝的数据——而 key 又在客户端 JS 里公开可见。

6.2 GraphQL 如何放大影响

Wiz 研究人员利用 GraphQL 绘制出完整的数据库模式。GraphQL 的内省与查询能力，在缺少 RLS 保护时，相当于给攻击者一张完整的「数据地图」——表名、字段、关系一目了然，后续批量导出成本极低。

6.3 暴露表清单（修复过程中发现）

蓝点网转述的涉及表包括（按修复顺序）：

第一批：agents、owners、site_admins
第二批：agent_messages、notifications、votes、followers
后续发现：observers（约 29K 邮箱）、identity_verifications、developer_apps

七、AI 生成代码的安全含义

蓝点网原文点出：Moltbook 本身完全依赖人工智能编码实现，这也凸显基于 AI 生成的代码可能存在重大安全隐患；作为人类控制者，可能需要仔细审阅代码。

可以拆成三句可执行的话：

AI 能写出能跑的 CRUD，写不出默认安全的权限模型。
云控制台里的「建议开启 RLS」不是可选项，是上线门槛。
人类 review 的对象不应只有业务逻辑，还应包括：公开 key 范围、表策略、私信/日志字段是否落密钥。

对投放、增长、运营类团队同样适用：内部工具、Demo、黑客马拉松产物一旦挂到公网域名，就会按「正式产品」被扫描。

八、自查命令与验证步骤（建议）

以下命令为通用 Supabase / PostgreSQL 安全自查思路，不针对 Moltbook 私有环境；具体表名与策略请以你们自己的 schema 为准。

8.1 检查 RLS 是否启用

-- 列出未启用 RLS 的表（PostgreSQL）
SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false;

若输出非空，这些表对持有 anon key 的客户端可能完全开放（取决于 GRANT 配置）。

8.2 检查 anon 角色的策略

SELECT tablename, policyname, permissive, roles, cmd, qual
FROM pg_policies
WHERE schemaname = 'public';

每张对外暴露的表都应有明确的 PERMISSIVE / RESTRICTIVE 策略；「没有任何 policy」在 RLS 开启时通常意味着全部拒绝，但 RLS 未开启时则意味着全部放行。

8.3 前端 key 泄露排查

# 在构建产物中搜索 Supabase URL / anon key 特征
grep -r "supabase" dist/ build/ .next/static/ 2>/dev/null
grep -rE "eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\." dist/ 2>/dev/null

若 anon key 出现在前端是 Supabase 的正常模式，但必须配合 RLS；service role key 绝不能出现在客户端。

8.4 匿名可读范围渗透测试（建议流程）

从公开 JS 提取 anon key；
用 Supabase 客户端或 curl 尝试读取每张表；
分别测试 SELECT 与 INSERT / UPDATE / DELETE；
对 GraphQL 端点做 schema 内省（若生产环境暴露）。

九、应急步骤（若你运营类似架构）

9.1 确认阶段

立即检查所有表的 RLS 状态；
从前端 bundle 确认暴露的是 anon key 还是 service role key（后者为紧急事故）；
评估已暴露数据的类型与规模；
检查日志是否有异常批量查询。

9.2 止血阶段

对所有表强制启用 RLS，默认 deny；
逐表添加最小权限策略；
若 key 已广泛泄露，轮换 Supabase anon key 与 JWT secret；
临时下线或限流 GraphQL 内省（若可行）。

9.3 轮换与通知

批量作废已泄露的 API 授权令牌（Moltbook 场景约 150 万级）；
通知受影响用户轮换 OpenAI 等第三方密钥；
审计私信、日志、webhook 中是否还有明文密钥；
向监管或用户按合规要求披露（视司法辖区而定）。

十、制度建议（建议）

10.1 上线门禁

AI 生成代码合入前，强制过安全 checklist：鉴权、多租户、RLS、密钥存储；
「能演示」与「能上线」分开审批；
RLS SQL 与策略文件纳入 Git，与业务代码同等 review。

10.2 密钥治理

OpenAI / 云厂商密钥一律服务端托管，禁止写入私信、日志、客户端；
智能体/用户私信字段做敏感信息扫描；
定期轮换与最小权限。

10.3 云 BaaS 专项

新表创建模板默认 ENABLE ROW LEVEL SECURITY；
CI 中加入「RLS 未启用 = 构建失败」规则；
每季度用空白外部账号做匿名可读范围复测。

十一、FAQ

Q：Supabase anon key 放在前端到底安不安全？

A：据 Supabase 官方设计与 Wiz 报告语境，公开 anon key 本身可以是正常架构——前提是 RLS 正确配置。Moltbook 的问题在于完全忽略 RLS，而非「key 在前端」这一件事。

Q：这次是谁发现的？

A：谷歌旗下网络安全公司 Wiz。蓝点网注明原始内容来源为 Wiz。

Q：攻击者需要复杂技巧吗？

A：不需要。蓝点网转述：Wiz 研究人员通过简单的漏洞即可渗透 Moltbook——核心是配置错误，而非 0day。

Q：修复用了多久？

A：从 2026-01-31 21:48 首次联系到 2026-02-01 01:00 最终修复，约 3 小时（UTC）。但窗口期内数据可能已被读取。

Q：AI 写的代码还能用吗？

A：蓝点网未给出「禁用 AI 编码」的结论，但明确指出人类控制者可能需要仔细审阅代码，尤其是权限与密钥相关配置。

Q：OpenAI 密钥是怎么泄露的？

A：在 AI 智能体之间的 4060 条私信中，Wiz 发现部分 OpenAI API 密钥以明文形式存在，可直接使用。

Q：人类用户的数据受影响吗？

A：是。超过 3.5 万个属于人类的电子邮件地址、约 2.9 万个早期注册邮箱，以及 observers 表中约 29K 邮箱均在暴露范围内。

十二、和我们日常系统的对照

错误假设	正确做法
key 在前端 = 数据也可以公开	key 公开，数据靠 RLS 策略隔离
AI 生成配置 = 跟官方最佳实践一致	必须人工对照 Supabase 安全文档
修了几张核心表 = 结束	全表复测 + 读写两侧都测
私信是「内部对话」	私信同样是攻击面与泄密面
论坛只是 Demo	挂公网域名就会被按正式产品扫描

十三、若你是类似架构的负责人：完整自查清单

13.1 Supabase / BaaS

每一张表是否强制启用 RLS？
anon 角色默认策略是否为 deny，再按需放行？
是否存在「为了省事」用 service role key 塞进前端的情况？（绝对禁止）
GraphQL / REST 的 schema 内省在生产是否必要开放？
是否有定期用空白小号做「匿名可读范围」渗透测试？

13.2 密钥与私信

智能体/用户私信、webhook、调试日志是否禁止明文密钥？
OpenAI / 云厂商密钥是否一律服务端托管 + 可轮换？
泄露窗口期内的令牌是否已批量作废并重发？

13.3 AI 辅助开发流程

生成代码合入前是否有安全 checklist（鉴权、多租户、密钥）？
「能演示」与「能上线」是否分开门禁？
基础设施即代码（RLS SQL、策略文件）是否进 Git 并被 review？

十四、来源与声明

本文事实依据：蓝点网《AI智能体专用论坛Moltbook数据库泄露暴露超过150万个API令牌和部分电子邮件地址》。

蓝点网注明原始内容来源为 Wiz。文中数字、时间线、表名、技术结论均转述自该报道，不另作未经证实的推测。第八、九、十节中的自查命令与制度条目为基于公开报道的通用安全建议，不代表 Moltbook 或 Wiz 官方指引。