AIのあとしまつ

事例・基礎知識

Moltbook・NauNau・DeepSeek——AIスタートアップの設定ミス型情報漏洩に共通するパターン

2026年のMoltbookデータ漏洩は、Supabaseの権限設定ミスが原因だった。NauNau・DeepSeekと並べると、vibe codingで作ったアプリに潜む「設定ミス型」漏洩の構造が見えてくる。

Moltbook 情報漏洩NauNau セキュリティAIスタートアップ データ漏洩Supabase 設定ミスvibe coding セキュリティ 事例設定ミス 情報漏洩AI生成コード セキュリティクラウド 設定ミス 漏洩

2026年2月、AIエージェント専用SNS「Moltbook」で約150万件のAPIキーと3.5万件超のメールアドレスが流出した。原因はSupabaseの権限設定ミスだ。

「認証なしで誰でもアクセスできる状態のデータベース」が外部に公開されていた。OpenAI APIキーなど第三者サービスの認証情報も含まれており、エージェントの乗っ取りが可能な状態だった——とZennの解析記事は報じている。

ただし、これは孤立した出来事ではない。同じ構造の事故が、他のスタートアップでも繰り返されている。

3つの事例に共通する「設定ミス型」漏洩の構造

Moltbook（2026年2月）

  • 原因： Supabaseの権限設定ミス。RLSが有効でも、全許可状態のポリシーが残っていたか、またはRLSが無効のままだった
  • 流出内容： 約150万件のAPIキー、3.5万件超のメールアドレス、数千件のプライベートメッセージ
  • 特徴： AIエージェント向けSNSという性質上、OpenAI APIキーなど第三者サービスのシークレットが大量に保存されていた。流出したキーを使えば、他ユーザーのエージェントを乗っ取れる状態だった

NauNau（2023年10月）

  • 原因： クラウドサービスのAPIへのアクセス制御の不足。モバイルアプリの通信を解析する程度の知識があれば、データベースから直接取得できた
  • 流出内容： 230万人以上のユーザーの位置情報・チャット履歴
  • 特徴： サービス開始（2022年9月）から発覚（2023年10月）まで約1年間、継続的にアクセス可能な状態が続いた。「画面が正常に動いている」状態でも、裏側のデータは全公開だった

→ NauNauの詳細な技術分析は位置情報アプリのRLS/Security Rules設定ガイドを参照

DeepSeek（2025年2月）

  • 原因： 認証なしでアクセスできるデータベースがインターネットに直接公開されていた
  • 流出内容： 100万件超のAPIシークレット、チャット履歴、内部情報
  • 特徴： 中国のAIスタートアップとして急成長中の段階で発生。「スピード優先の初期フェーズ」で設定が後回しになっていたと見られる

3つに共通する失敗パターン

これらは偶然の一致ではない。同じ構造的な問題が原因だ。

パターン1: デフォルトまたは開発用設定のまま本番公開

Supabaseは新規テーブル作成時、デフォルトではRLSが無効だ。「とりあえず動かす」段階で全許可設定にしたものを、本番公開前に戻し忘れる。Firebase/Firestoreでも同様に、allow read: if true が開発中に使われ、そのままリリースされる。

パターン2: 「動いている = 安全」の誤認

アプリの画面は正常に動く。ユーザーは自分のデータを見られる。ログインも機能する。しかしAPIを直接叩くと、他ユーザーのデータも取れる——この状態は、通常の動作テストでは発覚しない。

パターン3: シークレットの集積リスクを低く見積もる

Moltbookの場合、ユーザーデータだけでなく、ユーザーが保存していたAPIキーも流出した。プラットフォーム自体がシークレットの集積場所になっていたが、そのリスクへの対処が不十分だった。

vibe codingで作ったアプリで確認すべきこと

これらの事例に共通する失敗は、「AIに指示して動くものができた」段階で本番公開した点だ。

Supabaseを使っている場合：

-- 全テーブルのRLS状態を確認（SQL Editorで実行）
SELECT tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public';
-- rowsecurity が false のテーブルが1つでもあれば要確認

確認すべき項目：

  • すべてのテーブルでRLSが有効か
  • USING (true) の全許可ポリシーが残っていないか
  • service role key がフロントエンドのコードに含まれていないか

→ 詳細な設定手順はSupabase RLS設定ガイドを参照

APIを使っている場合（Moltbook型の対策）：

APIキー・トークン・シークレットはデータベースに保存せず、保存する場合は暗号化する。保存されているシークレットは最小権限（必要なスコープだけ）で発行し、定期的にローテーションする。万一の流出時の影響範囲を限定しておく。

認証なしのエンドポイントを確認する（NauNau型の対策）：

すべてのAPIエンドポイントに対して、認証なしでアクセスしたときに 401 Unauthorized が返るかテストする。

# 認証なしでAPIを直接叩いてみる
curl https://yourapp.com/api/users
# 200が返ったら問題あり。401が返れば正常

「スタートアップだから」は関係ない

3つの事例はいずれもスタートアップが起こしたが、規模の問題ではない。MoltbookもNauNauも、ユーザーが増えた段階で外部に発見された——攻撃者は「価値のあるデータがあるサービス」を自動的にスキャンしている。

「小規模のうちは問題が起きにくい」は逆だ。規模が小さいほど、インシデントが起きたときの回復力（対応人員・法務体制・広報体制）が低い。

vibe codingのスピードで作れるプロダクトが増えるほど、こうした設定ミスの事故も増える。「動くから本番に出す」前に、1時間の確認作業が何百万件の流出を防ぐ。

→ 本番公開前のセキュリティチェック全体像はAI生成コードのセキュリティリスク10選を参照

→ 非エンジニア向けのセキュリティ対策はVibe Codingで最低限やるべきセキュリティ対策にまとめている

ブログ一覧へ戻る