事件經過
全 AI 生成的爆紅網站： Moltbook 是一個專供 AI 助理（Agent）發文、留言與投票的社群網站，上線短短幾天內就在 AI 圈引起廣泛關注。創辦人曾公開自豪地表示，這個網站並非手寫程式打造：「我沒有為 Moltbook 寫過任何一行程式碼。我只是提出技術架構的想法，然後由 AI 來實現。」
幾分鐘內被看破手腳： 資安公司 Wiz 以一般訪客的身分瀏覽該網站，幾分鐘內，就在網站傳送給瀏覽器的網頁檔案裡找到了一把資料庫金鑰。他們拿這把金鑰向資料庫查詢，資料庫竟給予了「管理員等級」的回應，直接交出了 150 萬枚已註冊 AI 助理的登入金鑰。
超過 475 萬筆機密外洩： 研究人員進一步盤點資料庫的每一張表，發現共有約 475 萬筆紀錄毫無防備。其中包括：17,000 多名真實人類擁有者的個人資料；為一項即將推出產品所蒐集的 29,631 組 email（兩處合計超過 46,631 組 email，註：Wiz 報告摘要中所寫的 email 總數較低，與其實際逐表盤點的數字有落差）；還有 4,060 組私人對話，部分對話內甚至包含了可用來登入其他付費服務的金鑰。數據顯示，網站對外宣稱的 150 萬個 AI 助理，對應著 17,000 名人類擁有者，平均每人掛載了 88 個 AI 助理。
修補過程漏洞百出： Wiz 當晚便私下聯絡維護團隊。團隊第一次修補只關閉了三張表（AI 登入金鑰、擁有者資料、網站管理員）。後續的修補才陸續涵蓋訊息、通知、投票和追蹤紀錄。更驚險的是，研究人員發現「修改內容」的權限竟然還是開著的，他們親自編輯了一則貼文當作測試，團隊這才再次進行修補將其擋下。隨後又冒出更多暴露的資料表，最終在初次聯絡後的幾小時內，才將所有漏洞全數關閉。團隊在幾小時後刪除了測試內容，並向研究人員致謝。
後續： Wiz 表示他們已將取得的資料刪除。但這份報告留下了一個無法回答的懸念：在資料庫完全不設防的這段期間，網站上的貼文、投票和衡量帳號聲望的積分（karma），是否早就被有心人士竄改過？此外，另一名獨立資安研究人員也各自發現了同一個資料庫設定問題，並由一家新聞媒體進行了報導。
主要來源——S1：https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys存檔快照
損失成因
- 權限規則從未開啟這套資料庫本來可以逐筆檢查使用者「能不能看」或「能不能改」特定資料，但這項功能必須手動開啟才會生效。在沒開啟的情況下，資料庫對任何請求都來者不拒，導致每位訪客拿到的金鑰都擁有了管理員等級的最高權限。技術名稱：列級存取控制（RLS）（row level security）
- 把萬能鑰匙大方放在網頁上將這類金鑰放在網頁裡本來是正常的作法，但它安不安全，完全取決於後台的權限規則有沒有設定好。在規則沒開的情況下把金鑰放進網頁，就等於把整個資料庫雙手奉送給每一個看到網頁的人。技術名稱：前端憑證暴露（client-side credential exposure）
- 「讀取」與「寫入」沒有同步封鎖讀取和寫入是兩種不同的權限。團隊修補時把敏感資料的「讀取」關掉了，但「寫入」的大門卻還是開著的，導致任何陌生人都能在不需證明身分的情況下改寫貼文。外人用這種方式竄改的內容，接著會被平台上的 AI 助理讀進去，當成正常內容持續傳播。技術名稱：未經身分驗證的存取（unauthenticated access）
預防方式
上線前，拿到一份逐張資料表的清單並作檢查
請當初架設資料庫的人列出每一張資料表，並在旁邊明確標明：這張表會不會拒絕陌生人讀取和寫入？請注意，這份清單每新增一張資料表就需要更新一次，因為系統新建的資料表，預設通常是對所有人開放的。
把你網頁裡的每一把金鑰，都當成已經公開
請直接假設陌生人手上已經拿到了這把金鑰，然後去問你的資料庫供應商或工程師一個問題：「如果一個人只拿這把金鑰、沒有其他東西，他能讀到什麼？能改動什麼？」確認這些權限是否符合你的產品規格。
「能不能改資料」和「能不能讀資料」要分開問
當有人回報漏洞修補完成時，請要求分別確認兩件事：「外人已經讀不到資料」且「外人已經不能編輯、新增或刪除資料」。在兩項都獲得確認之前，請假設你公開展示的任何內容，都有可能已經被別人竄改過。
核心觀念： 一把「公開也無妨的金鑰」和一把「能交出整個資料庫的金鑰」，從外面根本看不出差異。只有背後的權限設定，才決定了你送出去的是哪種金鑰。