Lovable 170アプリ情報漏洩

スウェーデン発のvibe codingスター

Lovableは、スウェーデン発のvibe codingプラットフォームでした。

「自然言語でアプリを作れる」という謳い文句で急成長し、多くのスタートアップや個人開発者に利用されていました。技術的な知識がなくても、アイデアを形にできる——そんな夢のようなサービスでした。

しかし2025年3月、その夢は悪夢に変わりました。

発見者Matt Palmerの報告

2025年3月20日、セキュリティ研究者のMatt Palmerは、Lovableで作られたサービス「Linkable」を調査していました。

LinkableはLinkedInプロフィールからWebサイトを自動生成するサービスです。Lovableの技術で構築されていました。

Palmerは、ある異常に気づきました。

Supabase Row Level Security（RLS）の不在問題

問題の核心は、Row Level Security（RLS） の設定が欠如していたことでした。

RLSとは、データベースの行（レコード）単位でアクセス制御を行う仕組みです。「このユーザーは自分のデータだけ見られる」「管理者は全データを見られる」といった制御を行います。

しかし、Lovableが生成したアプリの多くで、このRLSが設定されていませんでした。

結果として、誰でも、全ユーザーのデータにアクセスできる 状態になっていたのです。

1,645アプリの調査

Replitの従業員が、Lovableの公式サイトで紹介されていた1,645のアプリを調査しました。

調査結果:

指標	数値
調査対象アプリ数	1,645
脆弱性のあるアプリ	170
脆弱なエンドポイント数	303
脆弱性の割合	10.3%

10アプリに1つの割合で、個人情報が誰でもアクセス可能な状態でした。

【事例】47分間のAI生成コード脆弱性悪夢

ソフトウェアエンジニアのDaniel Asariaは、この脆弱性の深刻さを実証しました。

彼は「top launched」（人気の高い）Lovableサイトに対して調査を行い、わずか47分 で以下の情報を抽出しました。

抽出された情報:

個人の借金額
自宅住所
AIサービスのAPIキー
「spicy prompts」（センシティブなAIプロンプト）
支払い情報
Google Mapsトークン
電話番号
サブスクリプション情報

47分で、複数のサービスの機密情報を根こそぎ取得できたのです。

AI生成コードで露出したJWTトークン

技術的に言えば、問題はさらに深刻でした。

LovableはバックエンドにSupabase（PostgreSQL + PostgREST）を使用していました。そして、匿名JWTトークン がフロントエンドのJavaScriptバンドルに露出していたのです。

これにより、攻撃者は以下のことが可能でした。

公開されているapp_idを取得（URLやマニフェストから）
露出したJWTトークンを使用
PostgREST APIに直接アクセス
RLSが設定されていないテーブルから全データを取得

認証をバイパスするために必要なのは、基本的なAPIの知識だけ でした。

【警告】45日間放置されたAI生成コード脆弱性

Matt Palmerは、2025年3月21日——発見の翌日——にLovableに報告しました。

しかし、事態は複雑な経過をたどりました。

タイムライン:

日付	出来事
3月20日	Palmer、脆弱性を発見
3月21日	Palmer、Lovableに報告
4月14日	Palantirエンジニアが独立して発見、X上で公開
4月24日	Lovable 2.0リリース（「セキュリティスキャン」機能付き）
5月29日	45日の猶予期間終了、CVE公開

「セキュリティスキャン」の虚偽

4月24日、Lovableは「Lovable 2.0」をリリースしました。目玉機能の一つが「セキュリティスキャン」でした。

しかし、このスキャンには重大な欠陥がありました。

問題点:

RLSの 「存在」 のみをチェック
RLSが 「正しく機能しているか」 はチェックしない
設定ミスのあるRLSポリシーを検出できない

結果として、開発者は「セキュリティスキャンをパスした」という 偽の安心感 を得ていました。実際には脆弱なままだったにもかかわらず。

CVE-2025-48757

45日間の猶予期間が終了した5月29日、Matt PalmerはCVE（Common Vulnerabilities and Exposures）を公開しました。

CVE-2025-48757

この脆弱性は、Lovableで生成されたすべてのアプリに潜在的に影響を与えるものでした。

AIは「頼み忘れたこと」を考慮しない

この事件の本質的な教訓は、以下の一言に集約されます。

“AI generates what you ask for, not what you forget to ask.” 「AIは頼んだことを生成する。頼み忘れたことは生成しない」

Lovableのユーザーは「アプリを作って」と依頼しました。しかし「セキュアなアプリを作って」とは明示していませんでした。

結果として、AIは機能的には動作するが、セキュリティ上は脆弱なアプリを生成したのです。

共有インフラが生むシステミックリスク

この事件は、vibe codingプラットフォームに共通する構造的な問題も露呈しました。

“All vibe coding applications run on the vendor’s shared infrastructure, meaning every customer inherits the vendor’s security posture.” 「すべてのvibe codingアプリケーションはベンダーの共有インフラ上で動作する。つまり、すべての顧客がベンダーのセキュリティ態勢を継承する」

プラットフォーム側にセキュリティの欠陥があれば、その上で構築されたすべてのアプリが脆弱になります。

これは単一障害点（Single Point of Failure）の問題であり、vibe codingの普及に伴って、そのリスクは拡大しています。

Lovableの対応

事件後、Lovableは以下の対策を発表しました。

AIによるセキュリティレビュー機能の強化
データベースセキュリティ問題の検出改善
コードインジェクション、XSS、認証脆弱性の検出

Lovableのブログには、こう記されています。

「Lovableは数ヶ月前と比べて、セキュアなアプリを構築する能力が大幅に向上しました。しかし、セキュリティに関して私たちが望むレベルにはまだ達していません。すべてのLovableユーザーのセキュリティ態勢を改善し続けることにコミットしています」

この事例から学ぶべき教訓

Lovable事件から学ぶべきことは以下の通りです。

AIはセキュリティを自動的に考慮しない
- 明示的に要求しない限り、セキュリティ機能は実装されない
「動く」と「安全」は別
- 機能的に動作することは、セキュリティを保証しない
プラットフォームへの依存はリスク
- 共有インフラの脆弱性は全ユーザーに影響
セキュリティスキャンを過信しない
- 「パスした」ことと「安全である」ことは異なる
vibe codingで本番サービスを運用するなら、セキュリティレビューは必須

まとめ：重要ポイントの振り返り

Lovableはスウェーデン発のvibe codingプラットフォーム
Row Level Security（RLS）の欠如により170アプリが脆弱
47分で借金額、住所、APIキー、支払い情報を抽出可能
45日間放置された後、CVE-2025-48757として公開
「セキュリティスキャン」機能も不完全だった
教訓：AIは「頼み忘れたこと」を考慮しない

【Lovable事件】170アプリから47分で機密情報流出