Moltbook 数据库完全开放：150 万个代理 API 密钥、3.5 万封电子邮件

Moltbook is a Reddit-style social network built so that only AI agents can post. Its founder, Matt Schlicht, launched it on 28 January 2026 and said publicly on X that he had not written a single line of its code: "I just had a vision for the technical architecture, and AI made it a reality," as Wiz quotes him. Three days later, on 31 January 2026, 404 Media reported that anyone could take control of any AI agent on the site. Wiz, which had found the same misconfiguration independently, published the technical account on 2 February: a Supabase API key hard-coded into Moltbook's client-side JavaScript pointed at a production database with no Row Level Security, and an unauthenticated request to the agents table returned live authentication tokens for the platform's agents, including its best-known ones. Wiz counted 1.5 million API tokens, 35,000 email addresses and 4,060 private agent-to-agent conversations readable that way, and confirmed it could also rewrite live posts. The archive files the episode as a critical-severity credential incident with a day-precision date of 31 January 2026, a confidence grade of A and recorded real harm, alongside the rest of its agent-infrastructure records in the Orca AI Incident Archive.

关键从来都不是秘密

Supabase is a hosted Postgres service with a REST API that Wiz describes as popular with vibe-coded applications because it is easy to set up. Its publishable key is designed to sit in client-side code: it identifies the project, and the access control is supposed to come from Row Level Security policies on the tables behind it. Wiz's Gal Nagli states the point explicitly in the write-up: exposing the key "does not automatically indicate a security failure," and when RLS is configured correctly "the public API key is safe to expose - it acts like a project identifier." In Moltbook's implementation, Wiz writes, "this critical line of defense was missing."

这个机制的起因是一个打包文件。据 Wiz 称，moltbook.com/_next/static/chunks/18e24eafc444b2b9.js 处的生产 JavaScript 文件同时包含 Supabase 项目地址 ehxbxtjliybbloantpwq.supabase.co 和密钥 sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-。随后，Wiz 向 agents 表发送了一个请求，要求获取三个名称和 API 密钥；该查询本应返回空数组或授权错误。它却返回了多行数据，其中包括该平台最受欢迎的一些 agent 的身份验证令牌。由此，Wiz 利用 PostgREST 错误消息和 GraphQL 内省梳理了模式，并统计出约 475 万条暴露记录。

该档案的摘要称，Moltbook“从未启用”行级安全（Row Level Security），而消息来源的说法比这更模糊。两者都没有展示配置历史，因此有记录可查的是：在审查期间，RLS 并未生效——Wiz 发现这些表处于开放状态，而 Implicator.ai 在转述发现者的说法时写道，Moltbook“从未开启 RLS。或者即便开启过，也没有配置任何策略”。无论是从未启用该设置，还是启用了但未配置任何策略，这两种说法都未能确认，而实际结果是一样的。

那些表格里实际上是什么内容

Wiz 指明了这些表及其内容。agents 表每行保存了用于验证该智能体身份的 api_key、用于认领其所有权的 claim_token、注册时签发的 verification_code，以及该智能体的 karma 和粉丝数。这并非单纯的数据泄露，而是一套完整的账户接管工具包：只要拿到其中一把密钥，请求就能以该智能体的身份发帖、发消息以及进行其他操作；Wiz 指出，这其中还包括高 karma 账户和知名人设智能体。

owners 表保存了超过 17,000 名用户的个人信息，包括电子邮件地址，以及每个智能体背后的 X 账号名和显示名称。Wiz 后来通过 GraphQL 端点发现的 observers 表则保存了另外 29,631 个电子邮件地址，这些地址属于 Moltbook 计划中的“Build Apps for AI Agents”产品的抢先体验注册用户。agent_messages 表保存了 4,060 段智能体之间的私密私信对话，存储时未加密，也没有访问控制；Wiz 报告称，其中一些对话以明文形式包含第三方凭据，包括智能体之间互相分享的 OpenAI API 密钥。

智能体与人类之间的比例，正是削弱该平台公开说法的部分。Wiz 报告称，有 150 万个注册智能体，而人类所有者约为 1.7 万，相当于每人约 88 个智能体，并将这一差距归因于缺乏速率限制或身份验证：任何人都可以循环注册智能体，而人类只需一个基本的 POST 请求就能以“智能体”的身份发帖。Wiz 的结论很直白——“这个革命性的 AI 社交网络在很大程度上是人类在操作成群的机器人。”

电子邮件数量无法清晰地对上，Wiz 也没有解释原因。其头条数字是 35,000 个电子邮件地址；其自己的表级计数是 17,000 多个所有者电子邮件和 29,631 个观察者电子邮件，两者相加约为 46,600。这两个数字都来自 Wiz，而本文并未查明 35,000 是如何得出的——是通过对两张表去重，还是来自在发现观察者表之前拍摄的快照。

曝光的写入部分

读取数据并不是全部发现。Wiz 报告称，即使第一轮修复阻止了对敏感表的读取访问，对公开表的写入访问仍然开放。它通过向一条线上帖子发送 PATCH 请求，并将其标题和正文替换为字符串“@galnagli - responsible disclosure test”来测试这一点，随后确认该编辑在网站上可见。在写入限制生效后，Wiz 无法再还原自己的测试帖子；Wiz 写道，Moltbook 团队几小时后删除了该内容，并感谢研究人员提交报告。

Wiz 所表达的担忧并非为了破坏而破坏。进入帖子的未经身份验证的写入路径意味着，任何人都可以向其他代理读取的内容中注入提示注入载荷；Wiz 将平台帖子、投票和 karma 在暴露窗口期间的完整性作为一个开放问题提出，而非一个经过测量的问题。本文所查阅的任何来源均未量化有多少内容被更改或被谁更改。

三小时十二分钟，四次单独修复

Wiz 的披露时间线始于 2026 年 1 月 31 日 21:48 UTC，当时通过 X 私信首次联系了 Moltbook 维护者；止于 2 月 1 日 01:00 UTC，此时最后一个暴露的表已得到保护。首次联系之后，该时间线还记录了另外七个步骤：22:06 的报告；23:29 的第一次修复，涉及 agents、owners 和 site_admins 表；00:13 的第二次修复，涉及 agent_messages、notifications、votes 和 follows；00:31 发现写入路径；00:44 的第三次修复将其关闭；00:50 发现 observers、identity_verifications 和 developer_apps 表；以及 01:00 的最终修复。

That timeline is the strongest argument against the simplest version of this story. Implicator.ai describes the fix in two SQL statements - it writes that "the fix required two SQL statements. They didn't exist," and the archive's summary carries the same "two lines of SQL" framing. The core repair for the read exposure probably was that small: enable RLS and add policies on the tables. But Wiz's own record shows four fixes across three hours, a second and separate write-access gap that the read fix did not close, and three further tables - including the 29,631 observer addresses - that surfaced only after the first two rounds. Wiz's closing lesson is that it "worked with the team through multiple rounds of remediation, with each iteration surfacing additional exposed surfaces." The two-line version describes the configuration change, not the remediation.

两项发现，以及记录中的一处差异

The find is usually credited to Jamieson O'Reilly, who founded the Australian security firm Dvuln, and who demonstrated the takeover to 404 Media; Implicator.ai reports that 404 Media verified the capability by updating O'Reilly's own Moltbook account with his permission. Wiz's post is by Gal Nagli and carries a note at the end crediting O'Reilly: "Security researcher Jameson O'Reilly also discovered the underlying Supabase misconfiguration, which has been reported by 404 Media." The note goes on to say that Wiz's post shares an independent discovery of the same issue.

The archive's summary describes both as Wiz researchers. Wiz's own post does not: it names Nagli as its author and describes O'Reilly as an independent researcher whose find 404 Media reported, and Implicator.ai places O'Reilly at Dvuln. The spelling is also unsettled across sources - Wiz writes "Jameson", while Dvuln's own site lists its founder as "Jamieson" - and this piece has used the spelling that site uses. What is not in dispute is that there were two independent discoveries of the same misconfiguration within days.

The account of the response differs by source, and the difference is worth reporting rather than resolving. On O'Reilly's account, relayed by Implicator.ai, he approached Schlicht directly and offered to help patch the flaw; the reply was: "I'm just going to give everything to AI. So send me whatever you have." A full day then passed without follow-up, according to that account, and Schlicht did not respond to 404 Media's request for comment. Wiz, contacting the maintainer separately, records its report filed at 22:06 UTC and the last of four fixes at 01:00 UTC, three hours and twelve minutes after first contact. The two timelines run on different channels and neither source says whether one prompted the other; both can be accurate.

记录确立了什么，以及没有确立什么

已确立的事实包括配置、数据类别、两次独立发现、修复顺序以及该平台的人员与智能体比例。该清单中的所有内容均来自 Wiz 的第一方技术文章，或基于发现者叙述的报道，而且两者在机制上说法一致。

尚未确定的部分，首先是有无先前访问。Wiz 表示，其研究和修复验证期间访问的所有数据均已删除，但这并不能说明其他任何人的情况。Implicator.ai 直言这一空白：没人能判断是否有人在 O'Reilly 之前发现了该数据库，也没人能判断在该平台爆红的那一周流传的帖子中，有多少是真正的智能体输出，有多少来自被盗密钥。本文查阅的任何消息源都没有报告任何已泄露凭据被确认滥用的情况，也没有报告实际被接管的账户数量。该存档的 real_harm 标志为 true，是因为个人数据和有效的第三方凭据确实可被任何人读取，而不是因为记录了具体的滥用行为。

智能体数量也相互矛盾，而且这种分歧追随的是平台的增长，而非泄露事件的事实。Implicator.ai 于2月1日根据发现者的叙述撰文，称有“3.2万多个”注册智能体——同一篇文章还说该网站在第一周就突破了3.7万——以及149万条泄露记录。Wiz 于2月2日复核时，统计到150万个智能体和约475万条记录。档案的摘要记载，该平台最终累积了170万个注册智能体和近700万条评论；本文没有独立证实这两个最终总数中的任何一个。所有说法都支持的一个数字是这件事的形态：智能体远多于人类，而且没有任何机制能分辨两者的差别。

发生了什么变化，以及该设置未能修复什么

所发生变化是有限且有据可查的：敏感表上的 RLS 策略、公共表上的写入限制、研究人员测试帖的删除，以及据 Wiz 称，平台已于 2 月 1 日 01:00 UTC 前完成全面修补。为本文所查阅的资料中，没有任何内容描述 Moltbook 增加了速率限制、智能体身份验证，或对事发时间窗口内所写内容进行审计。Wiz 的建议针对的是工具而非平台——生成 Supabase 后端的 AI 助手可以默认启用 RLS，部署平台则可以扫描暴露的凭据和不安全的配置。

比 SQL 存续更久的部分，是数据库使之显现的那个前提。一个以“只有 AI 智能体才能发帖”为卖点的网络，却无法验证一个智能体确实是智能体；而它的凭证层，是挡在一个拿着脚本的人类与站点上每一个身份之间的唯一屏障。正因如此，这份记录被归为标志性事件，而非例行配置错误：暴露本身很普通，但它所暴露的东西——面向自主智能体的已认证身份层——并不普通。