Lovableの48日間マルチテナント欠陥——BOLAで他ユーザーのソースコード・DBクレデンシャルが誰でも閲覧可能だった

何が起きたのか

2026年4月20日、セキュリティ研究者の**@weezerOSINT**がXで次の主張を公開した。

「Lovableの無料アカウントを作れば、他のユーザーのソースコード、データベース認証情報、AIチャット履歴、顧客データが読み取れる。これはNovember 2025以前に作られたすべてのプロジェクトに影響する。」

この主張は即座に複数の独立した研究者によって再現され、Lovableは翌2時間以内に修正を配布した。しかし問題はこの脆弱性が48日間放置されていたこと、そしてHackerOneへの報告が握り潰されていたことにある。

タイムライン

2026年2月3日  : バックエンド変更により公開プロジェクトの
              チャット履歴・ソースコードが誰でもアクセス可能な状態に
              （意図しないリグレッション）

2026年2月22日 : 最初の脆弱性報告がHackerOneに提出
2026年3月3日  : 2件目の報告（HackerOne #3583821）
              → いずれも「意図的な動作」として閉鎖

2026年4月20日 : @weezerOSINTが公開PoC・Xでのスレッド公開
              → Lovableが「ブリーチはない」「意図的な動作だ」と否定
              → 研究者コミュニティが大規模な再現に成功

2026年4月20日（数時間後）: Lovableが修正を配布
              → X上の声明を削除しHackerOneを非難する声明に変更
              → 「公開」と「非公開」の定義が不明瞭だったと釈明

技術的な脆弱性：BOLA（Broken Object Level Authorization）

脆弱性の本質はOWASP API Security Top 10の第1位、**BOLA（Broken Object Level Authorization）**だ。

BOLAとは:

  ❌ 脆弱なAPI（Lovableの場合）:
    GET /api/projects/{projectId}/chat-history
    → サーバーはprojectIdが
      「リクエスト送信者のものか」を検証しない
    → 任意のprojectIdを指定すれば他人のデータが返る

  ✅ 正しい実装:
    GET /api/projects/{projectId}/chat-history
    → サーバーが確認すること:
       1. リクエスト送信者は認証済みか？
       2. 送信者はprojectIdの所有者か？
       → 両方YESでなければ403を返す

攻撃者（研究者）は無料アカウントを作成し、公開されているプロジェクトリンクをインクリメンタルに変化させるだけで任意のプロジェクトデータを取得できた。

何のデータが漏洩したか

漏洩したデータ（確認済み）:
  ☠ ソースコード全体
    → アプリのロジック・独自アルゴリズムが丸見え

  ☠ Supabaseクレデンシャル（ハードコード）
    → 接続文字列からライブDBに直接クエリ実行が可能
    → 実名・役職・LinkedInプロフィール・Stripe顧客IDを取得

  ☠ AIチャット履歴
    → プロダクトの意思決定過程・機密要件が露出

  ☠ 顧客データ
    → アプリが収集していたエンドユーザーの個人情報

ハードコードされたSupabase URLとAPIキーを使って研究者はライブデータベースに直接接続し、個人情報を取得した。これは脆弱性の二重化（チャット履歴閲覧 + DBへの直接アクセス）を意味する。

HackerOneの機能不全

今回のインシデントで最も批判を集めたのは脆弱性そのものよりもバグバウンティプログラムの運用だ。

HackerOne報告処理の問題:

  2月22日: 研究者Aが報告 → 「意図的な動作」として閉鎖
  3月3日:  研究者Bが報告（#3583821）→ 重複扱いで閉鎖

  理由: Lovableが「公開プロジェクトのチャット閲覧は意図的」と
        HackerOneのトリアージチームに説明していた古いドキュメントが
        そのまま適用され、セキュリティチームにエスカレーションされなかった

Lovableは事後声明で「HackerOneのトリアージパートナーに提供していた内部ドキュメントが古く、publicの定義が不明瞭だった」と説明した。

しかし研究者側は「48日間で複数の報告が全て却下された」事実を指摘しており、プロセスの構造的問題として議論が続いている。

Lovableの対応を評価すると

対応の採点:

  ✅ 修正速度: 公開から2時間以内 → 迅速
  ❌ 初期対応: 「ブリーチはない」と否定 → 信頼毀損
  ❌ 責任所在: HackerOneに責任転嫁 → さらに信頼毀損
  △ 再発防止: 「ドキュメントを更新する」のみ → 具体性不足

初期の「意図的な動作」発言がX上で拡散し、その直後に声明が削除されたことで、コミュニティの不信感は脆弱性の深刻さを超えた。

バイブコーディングプラットフォームが抱える構造的リスク

Lovableの事例はAIが生成したアプリを「即デプロイ」するバイブコーディングプラットフォーム固有のリスクを浮き彫りにする。

バイブコーディングプラットフォームの構造的問題:

1. テナント分離の甘さ
   → AIが"動くコード"を生成することへの集中
   → マルチテナント設計・認可の検証が後回しになりやすい

2. クレデンシャルのハードコード
   → AIが生成するコードはデモ動作優先で環境変数より直書きを好む
   → Supabase/Firebase URLがソースに平文で残りやすい

3. "公開"の定義の曖昧さ
   → 「プロジェクトを公開する」= URLを共有できる
   → ≠ 「プロジェクトのソースを誰にでも閲覧させる」
   → この区別がUIにも実装にも明確でない

開発者が自分のプロジェクトで防ぐために

1. すべてのAPIエンドポイントで所有権を検証する

// ❌ 脆弱なパターン
app.get('/api/projects/:projectId/files', async (req, res) => {
  const files = await db.getProjectFiles(req.params.projectId);
  res.json(files);
});

// ✅ 正しいパターン
app.get('/api/projects/:projectId/files', authenticate, async (req, res) => {
  const project = await db.getProject(req.params.projectId);

  // 所有権チェック
  if (project.ownerId !== req.user.id) {
    return res.status(403).json({ error: 'Forbidden' });
  }

  const files = await db.getProjectFiles(req.params.projectId);
  res.json(files);
});

2. クレデンシャルを環境変数に分離する

AIが生成したコードに接続文字列がハードコードされていないか定期的に確認する。

# ソースコードからSupabase URLを検索
grep -r "supabase.co" . --include="*.ts" --include="*.js"
grep -r "eyJhbGci" . --include="*.ts" --include="*.js"  # JWT token pattern

# git履歴からも検索
git log --all -p | grep -E "(supabase|mongodb\+srv|postgresql://)"

注意点・未確認情報

実際に悪意ある第三者によってデータが取得されたかは非公開（Lovableは「研究者以外の悪用は確認していない」と声明）
影響を受けたプロジェクトの総数は非公開
規制当局（GDPR/CCPA）への報告状況は不明

まとめ

Lovableは48日間、BOLA脆弱性により他テナントのソースコード・DBクレデンシャル・チャット履歴を誰でも閲覧できる状態だった
HackerOneへの複数報告が「意図的な動作」として却下されたことが被害を拡大させた
バイブコーディングプラットフォームはテナント分離・認可設計・クレデンシャル管理に固有のリスクがある
すべてのAPIエンドポイントで所有権チェックを実装し、AIが生成するコードのクレデンシャルをレビューする

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感