Lovableで公開されていたアプリから18,000人分のデータが露出 ― Vibe Codingが生む「動くが危険なコード」の構造的問題

本稿では、AI開発プラットフォームLovable上で公開・紹介されていたアプリケーションから18,000人超のユーザーデータが未認証でアクセス可能な状態にあったとする報告（2026年2月27日報道）を起点に、Vibe Codingが内包するセキュリティリスクの構造と、IT現場が直面する「セキュリティ責任の空白地帯」について解説する。

露出の経緯と技術的原因
1. 単一アプリから16件の脆弱性、うち6件がクリティカル
2. AIが生成した「逆転した認証ロジック」
繰り返されるLovableのRLS問題
Vibe Codingのセキュリティ実態を示す複数の調査
実務視点での考察：「動くが安全でないコード」の構造的問題
参考情報

露出の経緯と技術的原因

単一アプリから16件の脆弱性、うち6件がクリティカル

セキュリティ研究者のTaimur Khan氏は、Lovableプラットフォーム上でホストされていた単一のアプリケーションから16件の脆弱性を発見したと報告した。うち6件はクリティカルと評価されている（The Register、2026年2月27日）。

当該アプリは試験問題の作成・成績閲覧を目的とした教育プラットフォームで、Lovableの「Discover」ページに掲載されており、10万回以上の閲覧と約400件のupvoteを獲得していた。Khan氏は情報開示プロセスの途中であるため、アプリ名を公表していない。

Khan氏によれば、露出していたレコードは合計18,697件、うち14,928件に一意のメールアドレスが含まれていた。内訳は学生アカウント4,538件（全件メールアドレス付き）、エンタープライズユーザー10,505件、フルPII（個人識別情報）が露出したユーザー870件である。ユーザーにはUC BerkeleyやUC Davisなど米国の大学関係者に加え、未成年を含む可能性のあるK-12教育機関のアカウントも含まれていたという。

AIが生成した「逆転した認証ロジック」

根本原因は、Lovableが生成するアプリのバックエンドであるSupabaseにおける、Row-Level Security（RLS）の未設定または不備にある。Lovable上のアプリはSupabaseをバックエンドとして使用し、認証、ファイルストレージ、PostgreSQLデータベース接続を処理する。AIまたはプロジェクトオーナーがRLSやロールベースのアクセス制御を明示的に実装しなければ、見た目は正常に動作するが実際にはセキュリティが機能しないコードが生成される。

Khan氏が発見した中でも典型的だったのは、認証関数のロジック反転である。Supabaseのリモートプロシージャコール（RPC）で実装されたアクセス制御は、管理者以外のアクセスをブロックする意図で書かれていたが、実際には認証済みユーザーをすべてブロックし、未認証ユーザーにアクセスを許可するという逆の動作をしていた。Khan氏はこの問題について「人間のセキュリティレビュアーなら数秒で検出するが、”動くコード”の生成に最適化されたAIコードジェネレータはこのまま本番にデプロイした」と述べている。

Khan氏の報告によれば、この認証不備により、未認証の攻撃者がすべてのユーザーレコードへのアクセス、プラットフォーム経由での一括メール送信、任意のユーザーアカウントの削除、学生の試験答案の採点、組織の管理者メールアドレスへの到達が可能な状態だった。実際にこれらが悪用されたかどうかは報じられていない。

繰り返されるLovableのRLS問題

今回の事案は孤立した事象ではない。2025年3月、Replit社員のMatt Palmer氏がLovable製サイト「Linkable」でRLS未設定の脆弱性を発見したのを皮切りに、Lovableの「launched.lovable.dev」に掲載されたプロジェクト全体を調査し、170件のWebサイトにまたがる303件のSupabaseエンドポイントでRLSが欠如または不備であることを確認した。この問題はCVE-2025-48757として2025年5月29日に公開されている（Palmer氏による声明）。

Palmer氏のタイムラインによれば、2025年3月21日にLovableへ報告したが実質的な対応はなく、4月24日にリリースされた「Lovable 2.0」に搭載されたセキュリティスキャン機能は、RLSポリシーの「存在」は確認するものの「正しさ」は検証しないものだった。45日間の開示期限が経過しても有意な修正がなされなかったため、Palmer氏はCVEを公開した。

今回のKhan氏のケースでも、Lovable側はサポートチケットを回答なしでクローズしたとされる。Khan氏は「10万人にアプリを見せ、自社インフラでホストしておきながら、データ漏洩を報告したチケットをクローズするのは無責任だ」と批判している。

一方、LovableのCISOであるIgor Andriushchenko氏はThe Registerの取材に対し、「正式な開示報告を受領したのは2月26日夜であり、数分以内に対応した」と説明した。また「Lovableで構築されたすべてのプロジェクトには公開前の無料セキュリティスキャンが含まれており、脆弱性が検出された場合は修正のための推奨事項が提供される。推奨事項の実装はユーザーの裁量に委ねられている。本件ではそれが行われなかった」と回答した。加えて「当該プロジェクトにはLovableが生成していないコードも含まれており、脆弱なデータベースはLovableがホストしたものではない」とも述べている。

Vibe Codingのセキュリティ実態を示す複数の調査

Vibe CodingはAndrej Karpathy氏が提唱した概念で、AIに自然言語で指示するだけでアプリケーションを構築する開発スタイルを指す。Collins Dictionaryの2025年Word of the Yearに選出されるほど急速に普及したが、Lovable固有の問題に留まらず、このアプローチ全体のセキュリティリスクを示す調査結果が複数公表されている。

セキュリティ企業Tenzaiは2025年12月に、Claude Code、OpenAI Codex、Cursor、Replit、Devinの5つのAIコーディングツールに同一のプロンプトで3種類のアプリケーションを構築させ、セキュリティを比較した。結果、15アプリから合計69件の脆弱性が検出された。全ツールがSSRF（Server-Side Request Forgery）脆弱性を生成し、CSRF保護を実装したアプリはゼロ、セキュリティヘッダーを設定したアプリもゼロだった。SQLインジェクションやXSSといった定型的な脆弱性は回避されていたが、認可ロジックの不備やビジネスロジックの欠陥など、コンテキスト依存の判断が求められる領域で一貫して失敗した（Tenzai、2026年1月）。

Veracodeの2025年GenAIコードセキュリティレポートは、100以上のLLMに80のコーディングタスクを実行させた結果、45%のケースでOWASP Top 10に該当する脆弱性が導入されたと報告している。Javaのセキュリティ不合格率は70%超、クロスサイトスクリプティング（CWE-80）の防御失敗率は86%に達した。LLMの構文的正確性は向上しているが、セキュリティ性能は経年で改善していないという点も指摘されている（Veracode、2025年7月）。

セキュリティ企業Escape.techは、Lovable、Base44、Create.xyz、Vibe Studio、Bolt.newの各プラットフォームで公開されている5,600件のアプリケーションをスキャンし、2,000件超の脆弱性、400件超の露出したシークレット、医療記録・IBAN・電話番号・メールアドレスを含む175件のPII露出を発見した。この結果はパッシブスキャンによる保守的な推定であり、より深い検査ではさらに多くの問題が見つかる可能性があるとしている（Escape.tech、2025年10月）。

実務視点での考察：「動くが安全でないコード」の構造的問題

セキュリティ責任の空白地帯

今回の事案が提起する核心的な問題は、技術的な脆弱性そのものではなく、Vibe Codingによって生じる「セキュリティ責任の空白地帯」である。

従来のソフトウェア開発では、開発者がコードの挙動を理解しているという前提に基づいてセキュリティの責任が割り当てられていた。しかしVibe Codingでは、プロンプトで要件を記述するだけでアプリケーションが生成される。生成されたコードのセキュリティ特性を理解しているのはAIでも人間でもない、という状況が構造的に発生する。

Lovableの対応がこの問題を象徴している。CISO Andriushchenko氏は「公開前にセキュリティスキャンを提供し、推奨事項を表示する」と述べるが、同時に「推奨事項の実装はユーザーの裁量」としている。しかしLovableのターゲットユーザーは、Supabaseのrow-level securityを理解し適切に設定できる開発者ではなく、プロンプトでアプリを作る非エンジニアである。推奨事項を見せられても、その意味と影響を正しく評価できるユーザーがどれだけいるかは疑問が残る。

Veracodeの調査が示す「LLMはセキュアな方法とインセキュアな方法のどちらかを選択する場面で45%の確率でインセキュアな選択をする」という結果は、AI側にもセキュリティの判断を委ねられないことを意味する。セキュリティの専門知識を持たないユーザーと、セキュリティに最適化されていないAIの組み合わせは、責任の所在が曖昧なまま脆弱なアプリケーションが本番環境に到達するパスを作り出す。

「Secure by Default」の欠如がスケールする

CVE-2025-48757とKhan氏の発見に共通する構造は、プラットフォームレベルのデフォルト設定がインセキュアであること、そしてその設定がAI生成コードを通じて大量のアプリケーションに複製される点にある。

Supabaseでは、Dashboardからテーブルを作成した場合はRLSがデフォルトで有効になるが、SQL EditorやmigrationsなどDashboard以外の方法で作成した場合はRLSが自動的に有効化されない（Supabase公式ドキュメント）。LovableのコードジェネレータがSupabaseとの連携でmigrations経由のテーブル作成を行う場合、RLSが未設定のまま本番に到達しやすい構造がある。手動でコードを書く開発者であれば、ドキュメントを確認しRLSを有効化する工程を経るが、AIコードジェネレータはその工程をスキップし、「動く」コードを即座に生成する。プロンプトでセキュリティ要件を明示しない限り、インセキュアなデフォルトがそのまま採用されるリスクがある。

Palmer氏の調査で170件のサイトに同一パターンのRLS欠如が確認されたという事実は、一つのインセキュアなデフォルトが数百のアプリケーションにスケールしうることを示している。これは個別のバグではなく、プラットフォームアーキテクチャの問題である。

シャドーVibe Codingという新たな脅威

Wiz Researchは、調査対象組織の5分の1がVibe Codingプラットフォーム上でアプリケーションを構築していたと報告している（Wiz Research、2025年9月）。これは従来のシャドーIT問題が「シャドーVibe Coding」として新たな形で再燃していることを示唆する。

筆者も過去に社内のシャドーIT調査に携わった経験があるが、当時強く感じたのは、利用者本人がシャドーITを「シャドー」だと意識していないケースが非常に多い点だった。特に目立ったのは便利ツールやコード管理ツールなど、現場の業務効率を独自に上げるために導入されたものだった。本人にとっては「業務改善」であり、セキュリティリスクを認識した上での判断ではなかった。

従来のシャドーITであれば、既存のアンチウイルスソフトやSaaS管理ツールで検知・対応できる場合も多い。しかしVibe Codingツールの場合、事業部門の担当者がLovableやBolt.newで数時間のうちに「動くアプリ」を作り、社内データベースやAPIキーを接続してしまう。シャドーITの発生速度が従来とは桁違いに速い上に、生成されたアプリ自体にKhan氏が報告したような認証ロジックの反転やRLSの欠如といった脆弱性が埋め込まれている可能性がある。

さらに懸念されるのは、今後無償のAIコーディングツールが増加する中で、生成されるコード自体に悪意あるコードが混入するリスクである。現時点でもAIコーディングツールが汚染されたサードパーティライブラリを提案するケースが報告されているが、AIが生成するコードそのものにバックドアや情報窃取の機能が含まれるようになれば、従来のシャドーITとは比較にならない被害規模に発展する可能性がある。

この問題は「発覚してから対処」では既に手遅れになりかねない。組織としてシャドーITおよびシャドーAI活用に関するポリシーを今のうちに策定し、社内プロキシやCASB（Cloud Access Security Broker）のログから主要なVibe Codingプラットフォームのドメインへのアクセス状況を可視化しておくことが、現実的な第一歩となる。

AI生成コードに対する組織的な防御策

シャドーVibe Codingの可視化に加えて、組織のセキュリティ体制に以下の観点を組み込む必要がある。

責任分界の明確化：Vibe Codingプラットフォームの利用規約と責任分界（共有責任モデル）を確認し、「プラットフォームがどこまで保証するのか」「ユーザーが負うべきセキュリティ責任は何か」をベンダー選定の評価項目に加える。今回のLovableの事案が示す通り、プラットフォーム側は「推奨事項の実装はユーザーの裁量」という立場を取ることがある。

AI生成コードへのセキュリティレビュー適用：Tenzaiの調査結果が示す通り、現行のAIコーディングツールはCSRF保護、セキュリティヘッダー、適切な認可制御といったプロアクティブなセキュリティ対策を自発的に実装しない。AI生成コードであっても、サードパーティソフトウェアと同等のセキュリティレビューを適用する必要がある。

Supabase利用環境のRLS監査：Supabaseを利用している場合、全テーブルでRLSが有効化されているか、ポリシーが意図通りに動作しているかを確認する。確認方法としては、匿名ユーザー・一般ユーザー・管理者の各ロールでの擬似アクセステストが有効である。RLSポリシーの「存在」だけでなく「正しさ」を検証する点が重要であり、Lovableのセキュリティスキャンはポリシーの存在確認のみでロジックの正当性は検証しない。

実際問題として・・・：とはいえ、情シスがすべてのAI生成コードをフルレビューするのは現実的ではない。まずは『顧客データや社内機密DBに接続するアプリ』のみをレビューの必須対象とし、それ以外の単体ツールは事業部側の自己責任とするなど、リスクベースのトリアージ基準を設けることから始めるべきだろう。