米国のクラウドデータベースを使うアプリで、約1万6000件のデータベースが外部から読める状態になっていた

何が起きたか

この事故で流出した、または流出したおそれがある情報は、約30万ドメインを調べ、1万6326件のデータベースで表が読めた。半数以上に個人情報。一部にパスワードと認証トークン、ごく一部にカード情報。例として米国の駐車代行サービスの顧客10万件超、カナダの移民手続きサービスの利用者約5000件（平文パスワード884件）があるです。その後の対応と影響は、UpGuardは影響の大きい運営者に連絡した。サービス会社の責任者は「安全な初期設定と道具を提供しており、設定は利用者が管理する」と述べた。第三者がデータを取得したかどうかは確かめられていないです。

原因になったのは「データベースの行単位アクセス制御（RLS）の未設定と公開キーの誤用」です。生成AIで作ったもの、または生成AIの使い方が事故に関わっています。

なぜ起きたか

管理画面で作った表は初期設定でRLSが有効になるが、SQLや他の道具で作った表は開発者が自分で有効にする必要がある。新しく作られるデータベースの6割超がAIを使った開発によるもので、UpGuardは運営者が設定を把握していないことが共通点だと説明した。すべてがAIで作られたことは証明されていない。

原因の種類は「設定ミス」です。公開範囲やアクセスの設定を誤り、外から見える状態になった事故を指します。このサイトに掲載している事故のうち、同じ種類の原因で起きた事故は13件あります。

事故が起きてから公表されるまで

1. UpGuardがサービスを使う約30万ドメインを調べる
2. 1万6326件のデータベースで表が読めることを確かめる
3. 影響の大きい運営者に連絡する
4. 2026年9月25日調査結果が報じられる

どうすれば防げたか

上の流れでは、最初から公表まで、途中で異常に気づいて止める仕組みが働いていません。

止められた可能性がある所（当社の見立て）

AIで作ったアプリを公開する前に、全ての表でアクセス制御が有効か、公開キーで読める範囲が意図どおりかを確かめていれば、外部から読める状態を防げた可能性がある。

この見立ては、公表された原因から当社が考えたものです。当事者の調査の結果とは異なる場合があります。

自社で確認する3つの手順

上から順に、短い時間で確認できるものを並べています。

1. 自社のアプリが使うデータベースの表を一覧にし、全ての表でアクセス制御が有効かを確かめる
2. ログインしていない状態で、公開キーを使って表が読めないかを試す
3. AIや外部に作らせたアプリは、公開前にデータベースの設定を人が確認する手順を入れる

自社に同じ原因があるか

当てはまるものを選んでください。1つでも当てはまれば、この事故と同じ原因が自社にもある可能性があります。

出典と更新の履歴

• Some Supabase customers are publicly exposing reams of people's data to the web（TechCrunch）2026.09.25
• Over 16,000 Supabase databases expose PII, passwords, auth tokens（BleepingComputer）2026.09.28