バイブコーディング ツールのLovable AIで情報漏洩の恐れ

2026年4月20日（日本時間4月21日）、セキュリティ研究者 @weezerOSINT がX（旧Twitter）にて、AIアプリ自動生成プラットフォーム「Lovable（Lovable.dev）」のAPIに重大な認可不備（BOLA）が存在すると公開しました。

この脆弱性により、無料アカウントを登録するだけで、他ユーザーが作成したプロジェクトのソースコード・データベース認証情報・AIチャット履歴・顧客データに無断でアクセスできる状態にあったとされています。研究者が脆弱性を報告したのは2026年3月3日であり、公開まで約48日間放置されていました。影響対象は2025年11月以前に作成されたすべてのプロジェクトとされており、数万規模の開発者およびそのエンドユーザーへの波及が懸念されています。

脆弱性の技術的詳細：BOLA（Broken Object Level Authorization）とは

今回確認された脆弱性クラスはBOLA（Broken Object Level Authorization）です。BOLAはOWASP API Security Top 10の第1位に位置する脆弱性であり、「ログイン済みかどうか」の認証は行うが、「そのリソースにアクセスする権限があるかどうか」の認可確認を省略している場合に発生します。

問題のエンドポイントは GET /projects/{id}/* で、Firebase認証トークンの検証は実施されていた一方、リソースのオーナーシップ確認がスキップされていました。任意のプロジェクトID（{id}）を指定するだけで、他ユーザーのプロジェクト情報一式が返却される状態でした。

研究者は「これはハッキングではない。無料アカウントからたった5回のAPIコールだ」と表現しています。

新旧プロジェクトで挙動が異なる

同一APIに対し、プロジェクトの作成時期によってレスポンスが分岐していることが確認されています。

新規ユーザーへのパッチは適用された一方、既存ユーザーへの修正は行われていないという非対称な状態が生じています。

研究者による実証内容

ソースコードへのアクセス

@weezerOSINT はデンマークの非営利団体「Connected Women in AI」のアクティブな管理パネルにアクセスし、ソースコードの取得に成功したと報告しています。このプロジェクトは2026年だけで3,700回以上の編集が加えられており、稼働中のプロダクションアプリに対して実証が行われたことになります。

認証情報の取得とDBアクセス

ソースコードにハードコードされていたSupabaseの認証情報（anon_key）を使い、本番データベースに対してSQLクエリを実行。AccentureデンマークおよびCopenhagen Business Schoolに所属する実在の人物の氏名・役職・LinkedInプロフィールURL・Stripe顧客IDを取得したと報告しています。

AIチャット履歴の露出

Lovableはユーザーとの会話履歴をプロジェクト単位で保存していますが、このチャット履歴も同一の脆弱なAPIから取得可能でした。開発者がLovableのチャット画面にペーストしたエラーログ・接続文字列・APIキー・ビジネスロジックの説明が、すべて第三者から読める状態にあった可能性があります。

影響企業の範囲

NVIDIAやMicrosoft、Uber、Spotifyの従業員アカウントが存在することが確認されており、これらの従業員が作成したプロジェクトも同様に露出していた可能性があります。

「48日間放置」の経緯

Lovable社の公式見解と批判

Lovableは公式声明として「データ侵害は発生していない」「”パブリック”設定の意味についてドキュメントが不明確だった」「チャット履歴がパブリックプロジェクトで可視であることは従来から仕様だった」「コードの可視性はパブリックプロジェクトにおいて意図的な設計だった」と発表しました。

しかしこの説明は、セキュリティコミュニティから強い批判を受けています。

ユーザーが「パブリック」に設定する際、自分のソースコードや認証情報が第三者に取得されると認識していたとは考えにくいという点が最大の問題です。

また、プロジェクトをプライベートに設定する機能は有料プラン限定であり、無料ユーザーはそもそも自衛手段を持ちません。「仕様」と「セキュリティ設計の欠陥」は別の話であり、命名の問題にすり替えても信頼回復にはつながらないとの声が相次いでいます。

過去の脆弱性との連続性（CVE-2025-48757）

今回の問題は孤立した事象ではありません。2025年3月にも類似した問題が報告されています。

CVE-2025-48757では、研究者Matt PalmerがLovable生成アプリ170件以上でSupabaseのRow Level Security（RLS）が未設定であることを発見しました。攻撃者はanon_keyを使い、認証なしでデータベーステーブルを読み書き可能であり、ユーザーリスト・支払いレコード・APIキーなどが露出していました。

LovableはRLSの「存在」を確認するセキュリティスキャン機能を追加しましたが、ポリシーの内容が正しく機能しているかの検証は行われておらず、偽の安心感を与えるだけだとして批判されました。公式Xへの「Lovable is now significantly better at building secure apps than a few months ago」という投稿に対し、コミュニティでは懐疑的な声が相次ぎました。

2025年の問題が「Lovableが生成したコードの問題」であったのに対し、今回のBOLA脆弱性はプラットフォームのAPIコントロールプレーン自体の欠陥です。開発者がどれほど注意深くコードを書いても、ユーザー側では回避できない性質の問題であり、より深刻な構造的問題といえます。

影響範囲の確認方法と緊急対応手順

Lovableを利用している、または過去に利用していたセキュリティ担当者は以下の手順で対応を進めてください。

Step 1：対象プロジェクトの特定

Lovableのダッシュボードで各プロジェクトの作成日を確認し、2025年11月以前に作成されたものを洗い出します。

Step 2：AIチャット履歴の監査

各プロジェクトのAIとの会話履歴を確認し、以下に該当する文字列が含まれていないかを調べてください。

sk-          # OpenAI等のAPIキー
Bearer       # Authorizationヘッダのトークン
postgres://  # PostgreSQL接続文字列
mysql://     # MySQL接続文字列
AKID / AKIA  # AWS Access Key

チャット履歴内に機密情報が存在した場合、それがすでに第三者に閲覧された可能性を前提に対処してください。

Step 3：認証情報のローテーション

Lovableのダッシュボード上で変更するだけでは不十分です。各サービスプロバイダー側で失効・再発行することが必要です。

Step 4：RLSの確認と修正

Supabaseを使用している場合、全テーブルに適切なRLSポリシーが設定されているかを確認してください。LovableのセキュリティスキャンはRLSが「存在するかどうか」しか検証しないため、ポリシーの内容は手動で確認する必要があります。

Step 5：個人情報露出の法的確認

日本国内ユーザーの個人データが含まれていた場合、個人情報保護法上の漏洩報告義務の対象になりえます。社内の法務・コンプライアンス担当と速やかに連携してください。

セキュリティ担当者へのインプリケーション

今回のLovable問題と、同時期に発覚したVercelのセキュリティインシデントを重ねると、AIネイティブ開発プラットフォーム全体に共通する構造的な問題が見えてきます。

開発速度・機能追加・ユーザー獲得を最優先で進めてきたプラットフォームの多くが、信頼境界（Trust Boundary）の設計を後回しにしてきた結果、今まさにその負債の回収を迫られています。「セキュリティは後からついてくる」というモデルが限界を迎えつつあるといえます。

社内でLovable・Bolt・Replitなどのバイブコーディングツールの利用を検討・許可している組織は、以下を評価基準に加えることを推奨します。

• 脆弱性報告への対応期間と透明性（SLAの開示はあるか）
• バグバウンティプログラムの運営状況
• プロジェクトのデフォルトが「パブリック」か「プライベート」か
• 無料プランでプライベート設定が可能か
• AIチャット履歴の保存場所・保存期間・アクセス制御の仕様

参考情報

• 【研究者X投稿】@weezerOSINT on X（2026年4月20日）
• 【報道】Cyber Kendra「Lovable Left Thousands of Projects Exposed for 48 Days」（2026年4月20日）
• 【報道】Cyber Security News「Lovable AI App Builder Reportedly Exposes Thousands of Projects Data via API Flaw」（2026年4月20日）
• 【報道】Economic Times「Lovable denies data breach, says public settings are ‘intentional’」（2026年4月20日）
• 【技術解説】Superblocks Blog「Lovable Vulnerability Explained: How 170+ Apps Were Exposed」（2026年3月）