2026年2月、1本のLovableアプリが18,697人のデータを世界に公開していた。作った人は何も悪いことをしようとしていなかったが、アプリは動きながら、同時に全員のデータをインターネットに向けて開け放っていた。
何が起きたか
セキュリティ研究者でテック起業家のTaimur Khanが、LovableのDiscoverページを眺めていた。DiscoverページはLovableが「いいアプリ」として紹介するギャラリーで、そこに掲載されることはプラットフォームのお墨付きを意味する。
目に止まったのは試験管理アプリだった。すでに100,000回以上閲覧され、約400件のアップボートを受けていた。ところが中を調べると、穴だらけだった。
The Registerの報道によれば（2026年2月27日）、このアプリには16件の脆弱性が存在し、うち6件はクリティカルに分類された。そして最大の問題は、データベースが完全に無防備な状態で、18,697件のユーザーレコードが外部から丸見えになっていたことだ。
誰のデータが露出していたか
このアプリは教育機関が利用する試験管理ツールだった。露出したデータの内訳は以下の通りだ（The Register より、2026年2月時点）。
- ユニークメールアドレス: 14,928件
- 学生アカウント: 4,538件（UC Berkeley、UC Davis、K-12教育機関の未成年を含む）
- エンタープライズユーザー: 10,505件
- 完全なPII（氏名・メール・個人識別情報がすべて揃ったレコード）: 870件
未成年のデータが含まれていた。成績が記録されていた。そしてそのアプリをLovableは自社のDiscoverページで紹介していた。
なぜ起きたか——認証ロジックの逆転
このアプリのバックエンドはSupabaseを使っていた。SupabaseはデータベースとPostgreSQL認証機能をセットで提供するサービスで、Lovableや類似ツールが自動生成するコードの定番構成だ。
Supabaseには「Row Level Security（RLS）」という仕組みがある。「ログインしたユーザーは自分のデータだけ読める」というルールをデータベースレベルで設定するもので、マンションで言えば各部屋の鍵にあたる。エントランスのオートロック（ログイン画面）があっても、各部屋に鍵がなければ住人なら誰の部屋にも入れてしまう。
このアプリにはRLSのポリシーが設定されていた。しかし、そのロジックが逆だった。
-- ❌ AIが生成した逆転ロジック
-- auth.uid() IS NULL は「ログインしていない場合に許可」という意味
CREATE POLICY "Users can read own data" ON exam_submissions
FOR SELECT USING (
auth.uid() IS NULL
);
ログインしている正規のユーザーがアクセスしようとすると弾かれる。ログインしていない攻撃者がアクセスすると、全データが返ってくる。警備員が招待状を持っている人を追い返し、何も持っていない人を通す仕様になっていた。
-- ✅ 正しいロジック
-- ログインユーザーのIDと一致するレコードだけ許可
CREATE POLICY "Users can read own data" ON exam_submissions
FOR SELECT USING (
auth.uid() = user_id
);
Khanはこの設計を「人間のセキュリティレビュアーなら数秒で気づく古典的なロジックの逆転」と表現した。AIはそれに気づかなかった。
AIは問われていないことには答えない。「ログイン機能をつけて」と頼んだだけでは、逆転したポリシーでも「ログイン機能がある」という意味で正しいコードとして出力される。「このポリシーで、ログインしていない人がデータを読めるようになっていないか確認して」と明示的に聞かなければ、確認しない。
攻撃者には何ができたか
RLSの逆転により、SupabaseのAnonymous Key（匿名キー）——これはクライアント側のJavaScriptに埋め込まれているため誰でも入手できる——を使えば、認証なしで全データに書き込み・削除まで可能だった。Khanが確認した操作のリスト（The Register より）:
- 全18,697件のユーザーレコードの閲覧
- 学生の成績改ざん
- 任意のアカウントの削除
- 全ユーザーへの一括メール送信
- 管理者のメールアドレスの取得
見知らぬ人間が全学生の答案用紙に自由に書き込める状態が、Lovableのギャラリーで紹介されたまま、100,000回以上閲覧され続けていた。
これは一件の事故ではない
このインシデントは偶発的な一件ではなく、構造的な問題の現れだ。
2025年3月、セキュリティ研究者のMatt Palmerが1,645個のLovableアプリをスキャンした結果、170個（10.3%）でRLS未設定によるデータ露出が確認された。この問題はCVE-2025-48757として登録されている（Superblocks より、2025年3月時点）。
Escape.techは5,600以上のバイブコーディングアプリを分析し、2,000件超の脆弱性、400件超の露出したシークレット、175件のPIIを発見した（Escape.tech より）。Wiz Researchはバイブコーディングプラットフォームを利用する組織の20%（5社に1社）がシステミックなセキュリティリスクを抱えていると指摘した（Wiz Research より）。
Veracodeの2025年調査では、AIが生成したコードの45%にOWASPトップ10に分類される脆弱性が含まれていることが判明した。そして「コードを生成するAIは賢くなっているが、安全なコードを書く能力は改善していない」というのが同報告書の結論だ（Veracode 2025 GenAI Code Security Report より）。
Lovableの組み込みセキュリティスキャンは、脆弱性を66%の確率でしか検出できないという調査結果がある（OX Security調査、Cybernews報告、2025年11月）。「Security Check: Passed」というバッジが表示されていても、安全とは限らない。
Lovableはどう対応したか
Khanは最初にサポートチケットを送った。返答はなく、チケットはクローズされた。
正式な開示レポートを送ると（2026年2月26日夜）、Lovableは「数分以内に対応した」と述べた。しかしLovableのCISO Igor AndriushchenkoがThe Registerに語ったコメントは、責任の所在をめぐる議論を呼んだ。
「Lovableで作ったプロジェクトはすべて、公開前に無料のセキュリティスキャンが含まれている。最終的には、そのレコメンデーションを実装するかどうかはユーザーの判断だ」「このプロジェクトにはLovableが生成していないコードも含まれており、脆弱なデータベースはLovableがホストしているものではない」
プラットフォーム側の見解は「スキャンは提供した。セキュリティの実装はユーザーの責任」ということだ。
一方でLovableはその後、Security Checker機能を強化し、1日約1,200件のAPIキー露出をブロックしていると報告している（Lovable公式ブログ より）。
Lovableは問題発覚後に対応を進めており、現時点では当時と同じリスクがそのまま残っているわけではない。ただし「セキュリティスキャンを通った＝安全」という前提は成り立たない。スキャンが検出できない脆弱性が存在することは調査が示している。
繰り返し現れる4つのリスクパターン
Wiz Research によれば、バイブコーディングアプリに繰り返し現れる脆弱性パターンは4つある。今回のインシデントも複数当てはまる。
自分のアプリを今すぐ確認する
Supabaseを使っているなら、以下の手順でRLSの状態を確認できる。
# RLS無効または逆転を確認するテスト
# anon keyでリクエストして全データが返ってくれば問題あり
curl \
-H "apikey: YOUR_ANON_KEY" \
-H "Authorization: Bearer YOUR_ANON_KEY" \
"https://YOUR_PROJECT.supabase.co/rest/v1/users?select=*"
# ← 全ユーザーのデータが返ってきた場合、RLSが無効または逆転している
問題が見つかった場合は、まず全テーブルのRLSを有効にし、ポリシーを設定する。
-- ✅ RLS有効化 + 正しいポリシーの設定
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
CREATE POLICY "ログインユーザーは自分のデータだけ読める" ON users
FOR SELECT USING (auth.uid() = id);
Supabaseのダッシュボードでは、各テーブルの「RLS enabled」インジケーターを確認できる。緑色になっていないテーブルは今すぐ確認が必要だ。
SentinelOneのCISO Alex Stamosはバイブコーディングのセキュリティについてこう述べた。「正しくやることはできる。でも正しくやれる可能性はきわめて低い」（Semafor より）。
「動いた」と「安全」は別の話
このアプリは動いていた。試験管理ツールとして機能していた。Lovableのギャラリーに掲載されるほど完成度が高いと評価されていた。ただ、18,697人のデータが開き放たれていた。
バイブコーディングは「作る」を速くする。しかし「動く」と「安全」は別の問題だ。AIは「セキュリティを確認して」と言われなければ確認しない。「ポリシーの向きが正しいか検証して」と言われなければ検証しない。
今あなたが作っているアプリのデータベースは、誰でも読めるようになっていないか。SupabaseのRLSは有効か。ポリシーのロジックは逆転していないか。動いているうちに確認してほしい。事故が起きてからでは遅い。