Moltbook 資料庫完全公開：150 萬個代理 API 金鑰、3.5 萬封電子郵件

Moltbook 是一個 Reddit 風格的社交網路，其設計讓只有 AI 代理能夠發文。其創辦人 Matt Schlicht 於 2026 年 1 月 28 日推出它，並在 X 上公開表示自己沒有寫過任何一行程式碼：「我只是對技術架構有一個願景，而 AI 讓它成真」，Wiz 引述他的話。三天後，也就是 2026 年 1 月 31 日，404 Media 報導任何人都能接管該網站上的任何 AI 代理。Wiz 獨立發現了同樣的錯誤設定，並於 2 月 2 日發表技術說明：一個硬編碼在 Moltbook 用戶端 JavaScript 中的 Supabase API 金鑰，指向一個沒有資料列層級安全性的正式環境資料庫，而對 agents 資料表發出未經身分驗證的請求，便回傳了平台上代理的即時驗證權杖，包括其中最知名的代理。Wiz 統計到有 150 萬個 API 權杖、35,000 個電子郵件地址，以及 4,060 段私密的代理對代理對話可透過這種方式讀取，並確認它也能改寫線上貼文。該檔案館將此事件歸檔為一起嚴重性為重大的憑證事件，日期精確到 2026 年 1 月 31 日，信心等級為 A，並記錄了實際損害，同時與其餘代理基礎設施記錄一同收錄於Orca AI Incident Archive。

關鍵從來不是秘密

Supabase 是一項託管的 Postgres 服務，提供 REST API，Wiz 形容它因為容易設定而深受 vibe-coded 應用程式歡迎。其可發布金鑰（publishable key）的設計是要放在用戶端程式碼中：它用來識別專案，而存取控制理應來自其後資料表上的資料列層級安全性（Row Level Security）原則。Wiz 的 Gal Nagli 在報告中明確指出：暴露該金鑰「並不自動代表安全失效」，而當 RLS 正確設定時，「公開 API 金鑰可以安全暴露——它就像專案識別碼」。Wiz 寫道，在 Moltbook 的實作中，「這道關鍵防線缺失了。」

這個機制的起因是一個打包檔。根據 Wiz 的說法，moltbook.com/_next/static/chunks/18e24eafc444b2b9.js 這個正式環境的 JavaScript 檔案同時帶有 Supabase 專案位址 ehxbxtjliybbloantpwq.supabase.co 與金鑰 sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-。接著 Wiz 向 agents 資料表送出請求，要求取得三個名稱與 API 金鑰；這筆查詢本應傳回空陣列或授權錯誤，結果卻傳回了資料列，其中還包括平台上最熱門的幾個代理的驗證權杖。Wiz 再從那裡利用 PostgREST 的錯誤訊息與 GraphQL 的 introspection 描繪出結構描述，並統計出約有 475 萬筆外洩紀錄。

該檔案庫的摘要說，Moltbook「從未啟用」Row Level Security，而來源的說法比那更寬鬆。兩者都未顯示設定歷程，因此有記錄的是：在審查期間 RLS 並未生效：Wiz 發現這些資料表處於開放狀態，而 Implicator.ai 在報導發現者的說法時寫道，Moltbook「從未開啟 RLS。或者如果有，也未設定任何策略。」該設定究竟是從未啟用，還是已啟用但沒有任何策略，兩種說法都無法確立，而實際結果相同。

表格裡實際上到底有什麼？

Wiz 指出了這些資料表及其內容。agents 資料表每一列存有：用來驗證該 agent 的 api_key、用來主張擁有該 agent 的 claim_token、註冊時核發的 verification_code，以及該 agent 的 karma 與追蹤者人數。這與其說是資料外洩，不如說是一套完整的帳號接管工具包：只要持有其中一把金鑰，請求就能以該 agent 的身分發文、傳訊及從事其他操作，而 Wiz 指出，其中還包括高 karma 帳號與知名人設 agent。

owners 资料表储存了超过 17,000 名使用者的个人资料，包括电子邮件地址，以及每个代理背后的 X 帐号名称和显示名称。Wiz 后来透过 GraphQL 端点发现的另一张资料表 observers，则存有另外 29,631 个电子邮件地址，属于 Moltbook 计划推出的「Build Apps for AI Agents」产品的抢先体验注册者。agent_messages 资料表存有 4,060 段代理之间的私人直接讯息对话，储存时未加密，也没有存取控制；Wiz 报告指出，其中一些对话以纯文字形式包含第三方凭证，包括代理彼此分享的 OpenAI API 密钥。

代理與真人的比例，正是戳破該平台公開說法的關鍵。Wiz 報告指出，註冊代理有 150 萬個，而真人擁有者約 17,000 名，相當於每人平均擁有約 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 的最終修復。

那個時間軸是反對這個故事最簡單版本的最有力論據。Implicator.ai 用兩條 SQL 陳述式描述這項修復——它寫道「這項修復需要兩條 SQL 陳述式。它們並不存在」，而存檔摘要也沿用同樣的「兩行 SQL」說法。讀取暴露問題的核心修復大概確實就這麼小：啟用 RLS 並在資料表上新增原則。但 Wiz 自己的紀錄顯示，三小時內共有四項修復、還有一個第二個且獨立的寫入權限缺口是讀取修復並未補上的，以及另外三張資料表——包括那 29,631 個觀察者位址——直到前兩輪之後才浮現。Wiz 的結語教訓是，它「與團隊合作進行多輪補救，而每一輪都浮現更多暴露面」。兩行版本描述的是設定變更，而不是補救。

兩項發現，以及紀錄上的一處差異

這項發現通常歸功於 Jamieson O'Reilly，他創立了澳洲安全公司 Dvuln，並向 404 Media 演示了這次接管；Implicator.ai 報導，404 Media 在獲得 O'Reilly 許可的情況下，透過更新 O'Reilly 自己的 Moltbook 帳號驗證了這項能力。Wiz 的文章由 Gal Nagli 撰寫，文末附註將功勞歸給 O'Reilly：「安全研究員 Jameson O'Reilly 也發現了底層的 Supabase 錯誤配置，此事已由 404 Media 報導。」該附註接著表示，Wiz 的文章分享的是對同一問題的獨立發現。

該檔案庫的摘要將兩人都描述為 Wiz 研究人員。Wiz 自己的文章則不是這麼說：它指名 Nagli 為作者，並將 O'Reilly 描述為獨立研究人員，其發現由 404 Media 報導，而 Implicator.ai 則把 O'Reilly 歸於 Dvuln。拼寫在不同來源之間也未有定論——Wiz 寫的是「Jameson」，而 Dvuln 自家網站則將其創辦人列為「Jamieson」——本文採用了該網站使用的拼法。無爭議的是，同一錯誤配置在幾天內有兩次獨立發現。

回應的說法因來源而異，而這個差異值得報導，而非加以釐清。根據 O'Reilly 的說法（由 Implicator.ai 轉述），他直接聯繫 Schlicht，並主動提出協助修補該漏洞；對方回覆：「我乾脆把一切都交給 AI。所以你手上有什麼就都寄給我。」根據該說法，之後整整一天過去，沒有後續消息，而 Schlicht 未回覆 404 Media 的置評請求。Wiz 另行聯繫維護者，記錄其報告於 UTC 22:06 提交，四項修正中的最後一項於 UTC 01:00 完成，距首次聯繫三小時十二分鐘。這兩條時間線發生在不同管道上，且兩個來源都未說明其中一方是否促使另一方行動；兩者可能都準確。

該紀錄確立了什麼，以及未確立什麼

已確立的事實包括組態、資料類別、兩項獨立發現、修復順序，以及該平台的人力與代理比例。清單中的每一項都來自 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 代理能發文」為賣點的網路，卻無法驗證某個代理是不是代理，而它的憑證層是擋在一個拿著腳本的人與網站上每一個身分之間的唯一防線。這就是為什麼這份紀錄被歸類為重大事件，而不是例行的設定錯誤：這次暴露本身很平常，但它所暴露的東西——供自主代理使用的已驗證身分層——並不平常。