Lovableのセキュリティ事故事例4選｜対策まで完全解説

Lovable（ラバブル）は、作りたいアプリを文章で伝えるだけで、AIが画面やデータの保存場所まで作ってくれるサービスです。プログラミングの経験がない人でも、社内ツールやお客さま向けのサイトを短時間で公開できます。

便利なぶん、公開したアプリの安全は誰がどこまで守るのか、という線引きが問われる事故が2025年から続いています。Lovableで作ったアプリの側に守りの抜けがあったもの、Lovableが悪用されたもの、Lovable側の不具合で本来見えないはずの情報が見えたものを、調べた範囲で4件にまとめました。

驚くのは、「こんなことで？」と思うほど日常的な操作が、入口になっている点です。アプリを作って公開する。作品を公開して共有する。文章で頼んで画面を作る。それだけで、利用者の連絡先や、プロジェクトの会話履歴が読める状態や、偽のログイン画面につながっています。

取り上げる4件は、性質がそれぞれ違います。事例ごとに、Lovableの機能が関わった範囲と、Lovableが取った対応を書き分けます。公表元の説明が食い違う点は、両方の主張を並べます。

本記事では、4件を「何が起きたか / なぜ起きたか / この失敗から学べる教訓(筆者の意見)」の3段構成でご紹介します。専門用語はそのつど説明しますので、開発の知識がなくても読み通せます。

Walkersでは「開発ノウハウがない」「最大限に効率よく開発を進めたい」企業さまに、事業を成功に導くAIエージェントによる開発支援を行っています。⇒開発支援サービスの概要はこちら

【事例①】Lovableで作ったアプリが、データの守りの設定が抜けたまま公開され、利用者の連絡先まで外から読めた

何が起きたか

2025年3月、開発者のマット・パーマーさんらは、Lovableで作られたサイトで、データの守りの設定が抜けていることに気づきました。最初に見つけたのは、LinkedInの経歴からサイトを作るLinkable（リンカブル）というサイトで、利用者の一覧表に入っているデータが、外から読める状態でした。同年5月には、欠陥の公開番号（CVE-2025-48757）が公表されています。

Lovableで作ったアプリは、データの保存を外部サービスのSupabase（スーパーベース）に任せる作りが一般的です。このサービスでは、データの表ごとに「誰が読めるか」を決める仕組み（行ごとのアクセス制限、RLS）を、作る側が設定する必要があります。この設定が無いか、中身が合っていないと、アプリの画面を通さずにデータを直接読めてしまいます。

研究者らは、Lovableの作品紹介ページに載っていた1,645件のアプリを調べました。170件（約10.3%）の303か所で、設定が足りていませんでした。外から読める状態になっていたデータには、利用者のメールアドレスや氏名、取引や契約の記録、外部サービスの鍵（API鍵）が含まれていたと、研究者は説明しています。

提供元のLovableは、この件に異論を示しています。公開番号の記録には「Lovableを使う個々の顧客が、自分のアプリのデータを守る責任を負うため、提供元は異論を示している」という趣旨の注記が付いています。一方、研究者の記録によると、Lovableは2025年4月24日に、公開時に問題を検査する機能（セキュリティスキャン）を加えています。

なぜ起きたか

原因は、データの守りの設定が「作る側の責任」に置かれているのに、文章で頼んで作る使い方では、その設定の有無に気づきにくいことです。画面は正しく動いても、裏側のデータが守られているとは限りません。研究者らは、当時の検査機能が「設定が存在するか」だけを見ていて、中身が正しいかまでは見ていないと指摘しています。

たとえるなら、店の入口に鍵をかけたつもりで、裏口の鍵を付け忘れていたような状態です。表から見ると店は普通に営業しているので、裏口が開いていることに、持ち主も気づきません。

この失敗から学べる教訓(筆者の意見)

この型の怖さは、利用者から見えない場所で、持ち主も気づかないまま、大量のデータが読める状態になることです。しかも画面の動作確認では見つかりません。

企業側にできる備えは、公開前に「ログインしていない人が、データを直接読めないか」を、画面ではなくデータの側で確かめることです。提供元の検査機能は役に立ちますが、それだけに任せず、中身を人が確かめます。ただし、これで100%防げるわけではありません。

線引きとして、お客さまの個人データを扱うアプリを、確認なしで公開しない決まりを置きます。守る責任が自社側にあるかどうかは、利用規約と社内規程の両方で、先に確かめておきます。

公開前のスキャンやRLSの確認など、Lovableで設定できるセキュリティ機能については、Lovableのセキュリティは本当に安全？【結論：設定次第】でまとめておりますので、そちらをご覧ください。

»出典： Matt Palmer「Statement on CVE-2025-48757」(2025-05-29)

＼特典：最適な開発方法をご提案／

【事例②】Lovableで作った偽のログイン画面が公開され、実在企業を装うメールの案内先に使われた

何が起きたか

2025年8月20日、セキュリティ会社のProofpoint（プルーフポイント）は、犯罪者がLovableを使って、だまし取りのためのサイトを作っていると公表しました。Lovableの機能で作ったサイトが、企業のログイン情報や、クレジットカードの情報を盗むために使われていた、という内容です。これはLovable自身のシステムが破られた話ではなく、Lovableの「サイトを短時間で作って公開する」機能が悪用された事例です。

Proofpointは、2025年2月以降、Lovableで作られた住所（lovable.app）のうち、毎月数万件がメールの中の危険なリンクとして検出されたと説明しています。例えば2025年2月には、ファイル共有を装うメール数十万通が、5,000を超える組織に届きました。メールのリンクの先には、計算問題を解かせる画面があり、解くと、本物そっくりのMicrosoftのログイン画面に移る作りでした。

同社は、配送会社のUPSを装うサイトや、暗号資産の運用サービスを装うサイトも確認しています。UPSを装うサイトは、カード情報などを盗み、チャットアプリのTelegram（テレグラム）に送っていました。無料で作られたLovableのサイトは、他の利用者が複製して作り直せる状態でした。

Lovableは、Proofpointからの報告を受けて、数百のドメインにわたるログイン情報狙いのサイト群を、同じ週に停止しました。Lovableは、2025年7月に、サイトの作成中にその場で悪用を検知する仕組みと、公開済みのプロジェクトを毎日自動で検査する仕組みを入れたと、Proofpointに説明しています。

なぜ起きたか

原因は、文章で頼むだけで、見た目の整ったサイトが作られ、そのまま公開用の住所まで付く手軽さが、悪意のある人にも同じように働くことです。Proofpointの研究者も、偽のサイトを作るときに、Lovableの側で止められることはなかったと書いています。

たとえるなら、誰でも借りられる印刷所が、どんな看板も注文どおりに作ってしまう状態です。住所が「lovable.app」であること自体は、安全のしるしにはなりません。見た目の手がかりが当てにならなくなる点に、この型の難しさがあります。

この失敗から学べる教訓(筆者の意見)

この型の怖さは、提供元の守りがどれだけ強くなっても、悪用する側と防ぐ側の追いかけっこが続くことです。Lovableは対策を重ねていますが、それが十分かどうかを、外から確かめる方法はありません。

企業側にできる備えは、メールのリンク先の住所だけで信用せず、ログインは必ず自社で決めた入口から行う決まりを置くことです。業務でLovableを使っていない会社でも、社員が偽のサイトに入力してしまう被害は起こります。ただし、これで100%防げるわけではありません。

線引きとして、自社の名前やロゴを使った偽のサイトが見つかったときの連絡先と、取引先への知らせ方を、事故が起きる前に決めておきます。

»出典： Proofpoint「Cybercriminals Abuse AI Website Creation App For Phishing」(2025-08-20)

【事例③】作品紹介ページで紹介されていたLovable製のアプリで、約1万8千人分のデータが、ログインなしで読めた

何が起きたか

2026年2月27日、イギリスのITメディアThe Register（ザ・レジスター）は、研究者のタイムール・カーンさんが、Lovableで作られたあるアプリに16件の欠陥を見つけたと報じました。うち6件は、特に深刻だったということです。カーンさんは、このアプリの名前を明かしていません。試験問題を作り、成績を見るためのアプリで、Lovableの作品紹介ページに載り、調べ始めた時点で10万回を超える閲覧がありました。

最も深刻だったのは、ログインの確認の条件が逆になっていたことです。本来は、管理者でない人を止める条件でした。しかし実際には、ログイン済みの人が止められ、ログインしていない人が通れる状態でした。同じ誤りが、複数の重要な処理で繰り返されていたといいます。

ログインしていない外部の人が、全利用者のデータを読み、一斉メールを送り、アカウントを消し、生徒の提出物に採点できる状態だったと、カーンさんは説明しています。利用者の記録は18,697件で、このうち14,928件に固有のメールアドレスがあり、870件は個人を特定できる情報がすべて見える状態でした。カリフォルニア大学バークレー校とデービス校の利用者や、未成年者を含む可能性のある学校の利用者も含まれていたと報じられています。

Lovableは、報告を2月26日の夜に受け、数分以内に動いたと説明しました。Lovableは、すべてのプロジェクトで公開前に無料の安全検査を受けられ、勧められた対応を実施するかどうかは、利用者の判断だと述べています。さらに、このプロジェクトには、Lovableが作っていないコードが含まれ、問題のデータベースはLovableが運用するものではなかったと説明しています。カーンさんは、問い合わせ窓口に出した報告が、返事なしで閉じられたと主張しており、両者の説明は食い違っています。

なぜ起きたか

原因は、管理者かどうかを確かめる条件が、逆に書かれていたことです。記事は、Lovableのアプリでは、データの守りの設定を明示的に作り込まないと、動いているように見えても欠陥を抱えうる、と説明しています。画面は動き、機能も揃っているので、持ち主には「ちゃんと作れている」ように見えます。

たとえるなら、社員証を確認する門番が「社員なら止める、他人なら通す」と逆の命令を受けていた状態です。毎日門の前に立っているので、安心して見えますが、中身は反対になっています。

この失敗から学べる教訓(筆者の意見)

この型の怖さは、作品紹介ページに載るほど注目されたアプリでも、基本的な守りが抜けていたことです。利用者の多さや見た目の完成度は、安全の証拠になりません。

企業側にできる備えは、公開前に「ログインしていない状態で、本来見えないはずのデータが見えないか」を実際に試すことです。作る人と試す人を分けると、見落としが減ります。ただし、これで100%防げるわけではありません。

線引きとして、提供元の検査機能の結果と、自社で行った確認の結果を、別々に記録しておきます。事故が起きたとき、誰がどこまで確かめていたかを、監査や取引先に説明できるようにするためです。

»出典： The Register「Lovable-hosted app littered with basic flaws exposed 18K users, researcher claims」(2026-02-27)

【事例④】Lovable側の不具合で、公開プロジェクトの会話履歴とソースコードが、他の利用者にも読める状態に戻った

何が起きたか

2026年4月20日、セキュリティ研究者が、Lovableの公開プロジェクトのデータが、ログインした利用者なら誰でも読める状態になっていると、SNSで公表しました。Lovableは、2026年2月3日から4月20日の間、公開プロジェクトの会話履歴とソースコード（アプリの設計図にあたるプログラム）が、プロジェクトのリンクを知っている利用者に読める状態だったと、認めています。

Lovableの無料プランでは、プロジェクトは長く「公開」が初期設定でした。公開にすると、アプリだけでなく、作成中の会話履歴やコードも他人に見えます。Lovableは、2025年を通じてこの公開範囲を狭めてきましたが、2026年2月に、バックエンドの不具合で、公開プロジェクトの会話履歴とコードへのアクセスが再び可能になったと説明しています。

報道によると、Lovableは当初、「データ漏えいではない」「意図した動作」と説明しましたが、同じ日にその説明を改め、謝罪しました。2026年4月22日の公式な説明では、2026年2月22日以降、複数の研究者が報告を出していたのに、外部の報告窓口（HackerOne）の担当が、古い社内資料に基づいて「想定どおりの動作」として閉じ、社内の安全の担当に上がらなかったと認めています。修正は、2時間以内に出されました。現在の公開プロジェクトは、公式テンプレートを除いて、すべて非公開に切り替えると説明しています。

報道によると、投稿した研究者は、他人のプロジェクトのデータベースの鍵まで読めたと主張しています。一方、Lovableの説明では、読めたのは公開プロジェクトの会話履歴とソースコードで、非公開のプロジェクトとLovable Cloud（Lovableが用意する保存場所）に影響はなかったとしています。この2つの説明は食い違っています。

なぜ起きたか

原因は、Lovable側の不具合です。2025年に一度閉じたはずの公開範囲が、2026年2月のバックエンドの不具合で、元に戻りました。「公開」という言葉も誤解されやすく、多くの利用者は、公開したアプリが見えるだけで、作成中の会話まで他人が読めるとは考えていなかったと、Lovableは説明しています。

たとえるなら、貸し会議室の「使用中」の札が外れて、会議の内容を廊下から見られる状態になったようなものです。利用者は札を貼ったつもりでも、貸す側の仕組みが変わると、前提が崩れます。

この失敗から学べる教訓(筆者の意見)

この型の怖さは、利用者に落ち度がなくても、提供元側の不具合で守りが外れることです。しかも、変更があったことは、利用者からは見えません。

企業側にできる備えは、会話の入力欄に、お客さまの個人データや、他のサービスの鍵を書かない決まりを置くことです。書いてしまった鍵は、漏れた疑いがあるものとして、すぐ交換します。ただし、これで100%防げるわけではありません。

線引きとして、業務で使うプロジェクトは、公開範囲を非公開にし、作成者を一覧で管理します。提供元に問題があったときの連絡窓口と、通知を受ける担当者も、契約の段階で確かめておきます。

プランごとに選べる公開範囲については、【2026年最新】Lovable(ラバブル)の料金プランを完全解説！で詳しくご紹介しておりますので、そちらをご覧ください。

»出典： Lovable「Our response to the April 2026 incident」(2026-04-22)

＼特典：最適な開発方法をご提案／

4事例に共通する「3つの落とし穴」

4つの事例は、入口も、起きた場所もばらばらです。それでも、共通する形があります。

落とし穴①「「ちゃんと動く」と「ちゃんと守られている」は別である」: 事例①③が示しています。画面もボタンも正しく動いているアプリで、裏側のデータが外から読める状態でした。動作確認は、守りの確認の代わりになりません。

落とし穴②「守る責任の境目が、使う側に伝わりにくい」: 事例①③④に当てはまります。Lovableは、アプリのデータを守る責任は作る側にあるという立場を取っています。一方で、「公開」の意味が誤解されたことも認めています。責任の境目は、契約や社内規程で先に確かめる必要があります。

落とし穴③「事故の原因は、利用者の手の届かない場所にもある」: 事例②④に当てはまります。偽のサイトを作る人も、提供元の内部で起きた不具合も、利用者の外側にあります。自社のアプリを正しく作るだけでは防げないため、使う側の運用で備える必要があります。

Lovableを使う企業が明日から打つべき3つの対策

ここでは、特別な知識がなくても始められる対策を、本当に大事な3つに絞りました。どれも「100%防げる」ものではなく、攻撃する側の手間を増やし、万一のときの被害を狭めるための現実的な一手です。

【対策①】公開する前に、ログインしていない状態でデータが読めないかを確かめる

事例①③に効きます。Lovableには、公開前に自動で動く簡易スキャンと、アプリ全体を調べる詳細スキャンがあり、データの守りの設定の抜けを調べられます。ただし、これは確認の入口であり、結果を鵜呑みにしません。

作った人とは別の人が、ログインしていない状態で、本来見えないデータが見えないかを実際に試します。個人データを扱うアプリは、この確認を終えるまで公開しない決まりにします。

【対策②】公開範囲を確かめ、鍵や個人データを会話の入力欄に書かない

事例④に効きます。Lovableの公式の説明では、プロジェクトの公開範囲（エディターで誰が見られるか）と、公開したアプリを誰が見られるかは、別々の設定です。業務のプロジェクトは非公開を基本にし、設定の画面で定期的に確かめます。

お客さまの個人データや、他のサービスの鍵は、会話の入力欄に書きません。すでに書いてしまった鍵は、漏れた疑いがあるものとして、すぐに交換します。

医療情報やカード番号など、Lovableで扱えないデータについては、【完全版】Lovableでできること/できないことを3分で解説！でまとめておりますので、そちらをご覧ください。

【対策③】lovable.appの住所を信用の根拠にせず、ログインは自社で決めた入口から行う

事例②に効きます。メールやチャットのリンクから、ログインや支払いの画面に進まない決まりにします。住所に有名な会社の名前が入っていても、本物かどうかの根拠にはなりません。

自社の名前を使った偽のサイトが見つかったときの連絡先も、前もって決めておきます。取引先への知らせ方まで決めておくと、被害が広がるのを抑えられます。

まとめ｜「使わない」ではなく「安全に使い倒す」へ

Lovableのような、文章でアプリを作るサービスを使うか使わないかは、もう論点ではありません。社内ツールや新しいサービスを、短い期間で形にできる便利さは大きく、避ける判断は、競合との差を広げられる機会を逃すことになりかねません。

残る論点は、作ったアプリのデータを誰が、どの段階で、どこまで確かめてから公開するのかを、誰がいつ決めるかです。ここを決めないまま使い始めた組織が、本記事の4つの事例と同じ入口に立っています。

Walkersでは、Lovableを含むAI開発ツールの活用の相談から、社内で安全に使うためのルール作り・定着までを、まとめて提供しています。「自社はどこから手を付けるべきか」がはっきりする初回相談を、無料でご用意しています。AIの知識がない経営者・担当者の方でも問題ありません。

Walkersに無料で相談する＞＞