第2回で扱ったMoltbook事件は、ある意味で「健全な事故」でした。創業者は3時間で問題を修正し、研究者の指摘に責任を持って応じました。3日で発覚し、3時間で塞がった。会社が小さく、判断する人間が少なかったから、修正もまた速かった。
だが、規模が大きくなると、何が起きるのか。
Stockholm発のvibe codingプラットフォームLovableは、評価額66億ドル（約1兆円）、ユーザー800万人、Uber・Zendesk・Deutsche Telekom・Microsoft・NVIDIA・Spotifyの従業員が業務利用する、ヨーロッパ最速で成長したスタートアップの一つです。
そのLovableは、2025年から2026年にかけて、まったく同じ構造の脆弱性を3回繰り返しました。最後の1回は、社内のバグ報奨金プログラムに正規に報告されてから48日間、放置されました。報告は届いていました。読まれて、「これは仕様です」と判断され、社内のセキュリティチームには上がらないまま、閉じられていました。
そして、ようやく公表されたとき、Lovableが最初に取った行動は——「これはデータ漏洩ではない」と否定することでした。
第1回で立てた構造命題が、規模を変えて2度目の現実化を迎えます。
1. Lovableというプラットフォームの構造
まず、Lovableが何をする道具なのかを正確に押さえておきます。これが、後の事故をすべて理解する鍵だからです。
Lovable（旧称GPT Engineer）は、自然言語のプロンプトでフルスタックWebアプリケーションを生成するプラットフォームです。「美容室の顧客管理システムを作って」と書けば、Reactのフロントエンド、Tailwindのスタイリング、Supabaseのバックエンド（PostgreSQLデータベース＋認証＋ストレージ）が、数分で生成され、そのままデプロイ可能な状態になります。コードを書く必要はありません。コードを読む必要すらありません。
Lovableは2025年12月に3億3,000万ドルのシリーズBを完了し、評価額66億ドルに達しました。CapitalG（Googleの成長ファンド）、Menlo Venturesがリード、NVentures（NVIDIAのVC部門）、Salesforce Ventures、Databricks Venturesらが出資しています。4週間で年間経常収益（ARR）400万ドルに到達するという爆発的成長を遂げ、ヨーロッパで最も急成長したスタートアップの一つに数えられています。
第2回のMoltbookは「個人がAIで作った1つのSNS」でした。Lovableは「個人がAIで作るプラットフォーム」そのものです。Lovable上で作られたアプリケーションは、Q1 2026時点で約800万件。複数の業界調査によれば、Fortune 500企業の87%が少なくとも1つのvibe codingプラットフォームを採用しているとされます（一次調査機関は特定できておらず、業界横断的な引用値）。
Lovableの内部設計には、後の脆弱性を構造的に運命づけた特徴がありました。
LovableはAIに「Supabaseに直接アクセスするフロントエンド」を生成させます。Webアプリのブラウザから、間にAPIサーバーを挟まずに、Supabaseにクエリを送る設計です。これは開発速度的には極めて効率的ですが、安全性の保証が「RLS（Row Level Security）ポリシーが正しく書かれていること」だけに集約されることを意味します。第2回のMoltbookで見た構造と、まったく同じです。
ただ、Moltbookは1人のユーザーが作った1つのアプリでした。Lovableは、この構造を800万人に量産させたプラットフォームです。
2. 2025年5月：最初の事件 ― 1,645アプリの10分の1が漏れていた
最初の警告は、2025年3月20日に発せられました。
警告したのは、競合のReplitに勤務するMatt Palmer氏（Developer Relations担当）。彼が偶然テストしていたのは「Linkable」というLovable製のサービスで、誰かのLinkedInプロフィールを自動的にパーソナルサイトに変換するツールでした。
Palmer氏は、APIリクエストから認証ヘッダーを外して再送信してみました。500人ほどのユーザー全員のメールアドレスが、認証なしで返ってきました。
驚いた彼は、同僚のKody Low氏とともに、Lovableが自社のショーケースサイトで紹介していた1,645個のアプリをスキャンするツールを書きました（詳細な発見プロセスはDesplega.aiに、Palmer氏本人の公式ステートメントはこちら）。結果はこうです——
| 指標 | 数値 | |
|---|---|---|
| スキャン対象アプリ | 1,645件 | |
| 重大な脆弱性を持つアプリ | 170件（10.3%） | |
| 露出した脆弱なエンドポイント | 303件 | |
| RLSがそもそも無効だったアプリ | 約70% |
これは、CVE-2025-48757として正式に登録された事件です（CVSS v3.1スコア9.3、Critical）。漏洩していたデータには、実名・自宅住所・LinkedInプロフィール・財務情報・個人債務残高・APIキーが含まれていました。1つのアプリでは13,000人のユーザーが影響を受けました。
Palmer氏は、責任ある開示プロセスに従いました。3月21日にLovable CEO Anton Osika氏に直接メールで報告。3月24日にLovableは受領を確認しましたが、実質的な回答はありませんでした。その3週間後の4月14日、PalantirのエンジニアDaniel Asaria氏が独立に同じ問題を発見し、わずか15行のPythonで複数のLovable製アプリから債務情報・住所・APIキーを47分で抽出してみせました。
それでも、Lovableは即座には動きませんでした。4月24日に「Lovable 2.0」をリリースし、新機能として「セキュリティスキャナ」を搭載——しかし、セキュリティ分析企業Superblocksの解析によると、このスキャナはRLSが「存在するか」を見るだけで、「正しく設定されているか」は検査しなかった。安全性は確認されないまま、確認されたという表示だけが返ってくる。これは「セキュリティ・シアター」と呼ばれました。
5月29日、Palmer氏は45日間の協調的開示期間が満了したと判断し、CVEを公表。同日、米メディアSemaforが報じた見出しは、これでした——
「最も話題のvibe codingスタートアップ Lovableは、ハッカーにとって格好の獲物だ」
ここで、Lovable CEO Osika氏とReplit CEO Amjad Masad氏の間でX上の応酬が起きました。Osika氏はこう投稿しました（趣旨）。
Replit創業者であること。10年のリードを持っていたこと。小さなEUの競合Lovableが利用数とvibe codingのセキュリティで自分を追い越すのを見ていること。それを4週間後にコピーすること。そしてLovableを「セキュアではない」と批判すること。
Masad氏の応答はもっと直球でした。
vibe codingはソフトウェア開発の民主化に大きく貢献した。我々は初心者開発者に低レベルのセキュリティ設定を監査することを期待できない。デプロイを簡単にするツールは、機密データを誤って晒すことも難しくすべきだ。
これは、第1回で立てた構造命題への、業界自身による応答でした——「動くを簡単にした以上、安全を難しくする責任は、ツール側にあるはずだ」。だが、その「はず」を実際に実装する責任は誰が取るのか。Lovableにとって、その質問の答えは、まだ「ユーザー側」だったのです。
3. 2026年2月：第二の事件 ― UC Berkeley/UC Davisが巻き込まれる
第一の事件から9ヶ月。Lovableはユーザー数を伸ばし続け、評価額は66億ドルに達しました。
2026年2月27日、技術起業家Taimur Khan氏が、Lovableが自社サイトで「成功事例」として紹介していた教育系アプリを調査しました。これは試験問題作成と成績管理のためのアプリで、UC Berkeley、UC Davisを含む米国の大学、K-12学校、ヨーロッパ・アフリカ・アジアの教育機関で実際に使われていました。
Khan氏が数時間で発見した脆弱性は、16件。うち6件はクリティカルでした。最も笑えない発見は、認証ロジックの実装ミスです——ログイン中のユーザーをブロックし、未認証のユーザーを通していた。順番が完全に逆だったのです（同事件のEdTech観点での詳細はvibegraveyard）。
漏洩したのは、18,697件のユーザーレコード。氏名・メール・所属・役割。すべて、認証なしでアクセス可能でした。
このとき、Lovableは2025年5月の教訓を活かしてはいたのです。2025年11月、デフォルトをprivateに変更しました。ユーザーが意図的にpublicを選ばない限り、新規プロジェクトはチャット履歴もソースコードも非公開になりました。
ただし、ここに後の事件の伏線が埋め込まれました。「2025年11月以前に作られたプロジェクトは、すべて引き続きpublicのまま」だったのです。
4. 2026年4月：第三の事件 ― 5回のAPIコールで他人のデータベース認証情報が手に入る
そして、2026年4月20日。
ハンドルネーム@weezerOSINTとして活動するセキュリティ研究者Matt Palmer氏（2025年5月の事件で報告した同じ人物）が、Xに投稿しました。
私は今日Lovableのアカウントを作成した。そして、他のユーザーのソースコード、データベース認証情報、AIチャット履歴、顧客データのすべてが、無料アカウントから読めることを確認した。
問題のエンドポイントは、https://api.lovable.dev/GetProjectMessagesOutputBody。所有権検証（ownership validation）が抜けていました。これは、OWASP API Security Top 10の第1位に挙げられているBOLA（Broken Object Level Authorization）——「壊れたオブジェクトレベル認可」と呼ばれる、API設計における最も基礎的な失敗パターンです（Halbornによるチャット履歴露出の業務リスク分析、影響範囲とSOC 2/ISO 27001観点の整理はBastion）。
研究者は、デンマークの非営利団体「Connected Women in AI」のアプリを実例として示しました。これは2026年だけで3,700回以上の更新が入っている、完全に現役のアプリでした。
そこから抽出されたのは——
- ハードコードされたSupabase認証情報
- それを使って引いたAccenture DenmarkとCopenhagen Business Schoolの専門職員の実名・職位・LinkedInプロフィール
- Stripe顧客ID
Palmer氏の言葉を借りれば、これは「ハッキングではない。無料アカウントからの5回のAPIコールだ」。
加えて、漏洩したチャット履歴の重みも、Moltbookの比ではありませんでした。Lovableのチャット履歴とは、開発者がAIに話しかけて作ったすべての記録です——アプリの仕様議論、データベーススキーマの設計、デバッグのために貼り付けられたエラーログ、そして「このAPIキーを使って繋いで」というやり取りそのもの。
ある研究者が抽出したチャットには、開発者がLovable AIにこう指示していた記録が含まれていました——「emailとdate_of_birthとstripe_customer_idを持つテーブルを作って」。すべて、平文で。誰でも読めました。
【露出期間と放置期間の区別について】
Lovable公式インシデントレポートおよびCyber Kendraの追加報道によれば、この脆弱性が外部からアクセス可能だった実際の露出期間は2026年2月3日〜4月20日の76日間にわたります（2月3日にバックエンドのリグレッションが導入され、所有権チェックが既存プロジェクトに対して効かなくなった）。本記事タイトルおよび以下で扱う「48日間」は、このうちMatt Palmer氏らによるHackerOne経由の正式報告（3月3日）以降に放置された期間を指します。
5. 48日間：報告は届いていた
ここからが、本記事の核心です。この脆弱性は、4月20日に公表される前に、報告されていました。
76日間の露出期間のうち、48日間はLovableに「すでに報告されている」状態でした。この48日間の中で、実際にどんな応酬が交わされていたのか。具体的な動きを時系列で追います。
48日間。バグは報告されていました。HackerOneという、世界最大のバグ報奨金プラットフォームの正規ルートで。
ところが、HackerOneのトリアージ担当者は、これを「公開プロジェクトのチャットが見えるのは仕様」と判断して閉じました。なぜなら、Lovableが彼らに渡していた内部ドキュメントが古く、「公開プロジェクトのチャットは公開」と書かれていたからです。Lovableは2025年11月にデフォルトをprivateに変更していましたが、トリアージ用のドキュメントは更新されていませんでした。
そして、修正は——新規プロジェクトにだけ適用されました。api.lovable.devは、2025年11月以降に作成されたプロジェクトには403 Forbiddenを返し、2025年11月以前のプロジェクトには200 OKで全データを返す、という状態になりました（既存ユーザー切り捨ての問題はCyber Kendraが指摘）。Palmer氏が再度報告すると、それは「重複」として閉じられました。
48日後、Palmer氏は公表を選びました。
6. 「データ漏洩ではない」 ― 否認の3段階
公表されてから24時間以内に、Lovableは3度、立場を変えました。
第1段階（同日）：否認
Lovableは公式Xで「我々はデータ漏洩を被っていない」と投稿。漏洩していたデータは「意図された動作（intentional behaviour）」だと主張しました。
第2段階（同日）：自社ドキュメントの責任に転嫁
数時間後、Lovableは立場を変更。「ユーザーがpublicとprivateの意味を誤解していた」「我々のドキュメントが不明確だった」と説明しました。漏洩自体は問題ではない、ユーザーの理解が問題だ、という構図です（「By Design」言い訳の構造的批判はAssessed Intelligence）。
第3段階（同日）：HackerOneに責任転嫁
さらに数時間後、Lovableは再び立場を変更。「報告は受け取っていた。しかしHackerOneのパートナーが、公開プロジェクトのチャットが見えるのは意図された動作と判断し、社内のセキュリティチームに上げなかった」と発表しました。
第4段階（同日深夜〜翌日）：謝罪
公衆の反発を受け、Lovableは最終的に謝罪しました。CEO Osika氏はLinkedInに投稿し、「私が責任を取る」と書きました。「Lovableは、ソフトウェアを構築するための最も安全な場所であるべきだ」「ドキュメントの問題を指摘するだけでは、十分ではなかった」（Sifted経由の謝罪声明より）。
セキュリティメディアCybernewsの見出しは、こうでした——「Lovableは脆弱性を否認するエゴ・トリップに出かけ、戻ってきて他者に責任転嫁した」。
7. 構造命題、3度目の現実化
第1回で立てた命題に戻ります——AIは「動く」ように最適化されている。「安全」に作るようには最適化されていない。
Lovableは、この命題をプラットフォームのレベルで実装しました。AIが生成するコードはRLS抜きでも動きます。デフォルトの設定で動きます。ユーザーがAIに依頼した瞬間、エラーは出ません。動きます。
そして、Lovableが3回繰り返した事件には、共通の構造があります。
第2回のMoltbookでは、この構造が個人の規模で発火しました。3日で発見され、3時間で修正されました。
第3回のLovableでは、同じ構造が66億ドル評価額・800万ユーザーのプラットフォーム規模で発火しました。13ヶ月で3回発火しました。最後の発火は48日間放置されました。最初の対応は否認でした。修正は「新規プロジェクトだけ」という、既存ユーザーを切り捨てる形で実装されました。
そして決定的に重要なのは、これら3回の事件のうち、1回も、Lovable自身の社内セキュリティチームが発見していないことです。すべて外部の研究者が——時には個人の競合企業の従業員が——テストの過程で偶然発見しました。Lovableの内部には、この種の脆弱性を発見する仕組みが存在していなかった、ということです。
8. なぜインセンティブ構造が、これを生み出すのか
Lovableは「ヨーロッパで最も急成長したスタートアップ」です。4週間でARR400万ドル、5ヶ月で評価額3倍、企業導入も急速な拡大を続けてきました。
Lovableは特殊にinsecure（脆弱）なのではない。Lovableはこのカテゴリーを代表してinsecureなのだ。
つまり、Lovable個社の問題ではなく、vibe codingプラットフォーム全体に共通するインセンティブ構造の問題だ、ということです。
市場が報酬するのは、スピードと成長です。3億3,000万ドルの調達は、「いかに早くユーザーを増やしたか」「いかに早くARRを伸ばしたか」で決まります。セキュリティに時間を費やすことは、競合に追い越される時間として処罰されます。Bolt.newはRLSをデフォルトでオフに出荷しています（Supabaseバックアプリのスキャン調査では、Bolt.hostのRLS誤設定率がLovableの4倍に達したという報告もあります）。Cursorは複数のCVEをパッチしています。Pillar SecurityはCursorとGitHub Copilotに対する「rules file backdoor」攻撃を実証しました（The Hacker Newsによる解説）。Lovableだけの問題ではありません。
そして、市場の側もそれを許しています。Fortune 500の87%が、こうしたプラットフォームを少なくとも1つ採用しているという業界調査もあります。Uberの従業員は、Zendeskの従業員は、Microsoftの従業員は、自社のセキュリティ部門が知らないところで、業務データをLovableのチャットに貼り付けています。
これは、第1回で立てた命題の最も冷たい帰結です——
個別のAIが「動く」ように最適化されているだけでなく、AIを取り巻く市場全体が「動く」ように最適化されている。そして「動く」ことで報酬される企業に、「安全」のために減速するインセンティブはない。
まとめ
Lovableは、Moltbookと同じ構造的脆弱性を、企業規模で・1年間で3回・組織的に放置した、最も鮮明な事例です。
5回のAPIコールで、無料アカウントから他人のソースコード、データベース認証情報、AIチャット履歴、顧客のStripe IDが手に入りました。実際の露出期間は76日、うち48日はHackerOne経由で正規に報告された後の放置期間でした。最初の対応は「データ漏洩ではない」という否認でした。修正は新規プロジェクトだけに適用されました。
これは、第1回の構造命題の3度目の現実化です——AIは「動く」ように最適化されており、AIを使うプラットフォームは「動く」を量産するように最適化されており、そして「動く」を量産する企業を、市場は「動く」によって報酬します。安全のための減速は、誰のインセンティブにも乗りません。
そしてLovableが特殊なのではなく、Lovableはこのカテゴリーを代表してinsecureだという事実は、800万のアプリと87%のFortune 500企業に対して、何を意味するのでしょうか。
次回（第4回）は、視点を変えます。これまではAIが作ったコードが漏らした事例でした。次は、AIエージェントが直接行動して企業のデータベースを破壊した事件を扱います。
舞台はReplit。被害者はSaaStr創業者Jason Lemkin氏。「コードフリーズ中」と何度も指示されていたAIエージェントが、その指示を無視して本番データベースを削除し、1,206名・1,196社のレコードを消滅させ、そして「ロールバックは不可能だ」と嘘をつきました。
「動く」と「安全」が違う言葉である、という命題が、最も狂気じみた形で現実化した瞬間です。
参考情報
Lovable: Our response to the April 2026 incident — Lovable自身による事件の公式説明と是正措置（露出期間76日も含む）
Anton Osika — Our response to the April 2026 incident（LinkedIn） — CEO本人による「I take accountability」声明
Matt Palmer氏 X (@weezerOSINT) — 公表当事者の研究者アカウント
Anton Osika氏 X投稿（2025年5月の応酬） — Replit/Masad氏との応酬の原典
The Register: Lovable denies data leak, cites 'intentional behavior' — 否認の3段階の詳報
Cybernews: Lovable goes on ego trip denying vulnerability, then blames others for said vulnerability — 強い批判的視点とConnected Women in AI実例
The Next Web: Lovable security crisis: 48 days of exposed projects, closed bug reports — vibe codingカテゴリ全体の構造分析
Cyber Kendra: Lovable Left Thousands of Projects Exposed for 48 Days — 既存ユーザー切り捨て問題の指摘
Cyber Kendra: Lovable Admits It Broke Its Own Security Fix — 露出期間76日（2/3〜4/20）のリグレッション認定
Sifted: Lovable CEO apologises after security scare: 'I take accountability' — Osika氏の謝罪声明とSifted独自取材
Business Insider: Lovable's security stumble shows one big risk in using AI to code — 5回のAPIコール露出事案の主流メディア報道
The Register: AI-built app on Lovable exposed 18K users, researcher claims — 2026年2月のUC Berkeley/UC Davis事件の主要報道
Taimur Khan氏 LinkedIn記事: Lovable? More Like Hackable. — UC Berkeley/UC Davis事件の発見者本人による詳細
Threat Landscape Blog: The Lovable.dev Data Breach Exposes the Dark Side of Vibe Coding — BOLA脆弱性の技術詳細
Bastion: Lovable Data Breach April 2026: What Was Exposed & How to Respond — 影響範囲とSOC 2/ISO 27001観点の整理
Halborn: Lovable Data Leak: BOLA Vulnerability and App Security Risks — チャット履歴露出の業務リスク分析
Assessed Intelligence: When "By Design" Is the Breach — 「意図された動作」言い訳の構造的批判
vibegraveyard: Lovable-showcased EdTech app found riddled with 16 security flaws — 認証ロジック逆転の技術詳細
Semafor: The hottest new vibe coding startup Lovable is a sitting duck for hackers — CVE-2025-48757の最初の大型報道
Superblocks: Lovable Vulnerability Explained: How 170+ Apps Were Exposed — CVE-2025-48757の技術解析（CVSS 9.3、170件露出の詳細）
Desplega.ai: Vibe Break Chapter IV: The Lovable Inadvertence — Palmer氏とAsaria氏の発見プロセス詳細
Matt Palmer: Statement on CVE-2025-48757 — 当事者本人による公式ステートメント
NVD: CVE-2025-48757 — 公式CVSSスコア9.3 (Critical) の登録情報
Pillar Security: New Vulnerability in GitHub Copilot and Cursor — How Hackers Can Weaponize Code Agents — Rules File Backdoor攻撃の一次ソース
The Hacker News: New 'Rules File Backdoor' Attack Lets Hackers Inject Malicious Code — Rules File Backdoorの一般メディア解説
GitHub Security Advisory: Cursor Agent RCE (CVE-2025-54135) — Cursorの公式CVE記録
この記事をシェアする
