16,000 Supabase Databases Exposed Names, Passwords and Auth Tokens to the Open Web

Sixteen thousand databases, wide open to anyone with a URL.

Security researchers at UpGuard found roughly 16,000 Supabase-hosted databases publicly exposing people’s personal data on the open web, according to research reported by TechCrunch on September 25. The exposed records included names, home addresses, phone numbers and user passwords — plus a smaller number of authentication tokens and, in rare cases, credit card data.

Cybernews, which reviewed the findings, put the count at 16,326 databases and noted that over half appeared to leak personally identifiable information.

The examples are not hypothetical

UpGuard didn’t just count databases. Its researchers sampled them to confirm the data was real, and the specifics are uncomfortable.

An Indian adult streaming site was exposing data on more than 65,000 people — including passport and driver’s license details, financial information and over 100,000 private messages. A Philippines-based OTP service left more than 100,000 SMS messages with one-time passcodes sitting in the open. A US valet parking service exposed information on over 100,000 customers, including license plate records. An African government’s consulate in France had a database containing personal and location information on 25,000 people. A Canadian immigration service leaked nearly 5,000 records, including 884 accounts with passwords stored in plain text.

One database even belonged to infrastructure tied to a virtual SIM farm used to intercept text messages for account-verification scams.

Nobody hacked Supabase

To be clear: this wasn’t a break-in. Supabase wasn’t breached. The root cause is customer misconfiguration — and increasingly, the misconfiguration has a very 2026 flavor.

Almost all of it comes down to Postgres row-level security, or RLS, the feature that decides which rows of a database table a given user is allowed to read. Supabase’s own dashboard turns RLS on by default when you create a table through its Table Editor. But AI coding tools don’t click through the dashboard. They write SQL migrations directly, and in that path, RLS defaults to off.

So the failure mode looks like this: a founder types a prompt into Lovable, Bolt or Replit, the AI ships a working app in an afternoon, and nobody ever flips the switch that keeps one user from reading every other user’s row. The app works perfectly. It also has no lock on the database.

UpGuard researcher Greg Pollock said the work was meant to raise awareness rather than to embarrass anyone. The pattern is old: exposed storage has leaked military emails, visa applications, driver’s license scans and children’s records for years — but AI-assisted development is feeding a fresh wave of it.

Supabase says it’s secure by default

Supabase Chief Information Security Officer Bil Harmer told TechCrunch the company hadn’t seen the research before publication, but said projects are “secure by default.” Customers control how their own projects are configured, he said, adding that Supabase notifies users when it detects exposure.

He has a point. RLS exists, the dashboard enables it by default, and Supabase provides the tooling. But the friction here is real: the fastest-growing way people build on Supabase — prompting an AI to generate the app — bypasses every default that was designed for humans clicking through a UI. When your growth story is vibe-coded apps, your security story can’t assume anyone reads the docs.

Supabase reached a $10 billion valuation earlier this year, riding exactly that boom. Thousands of AI-built apps now store their databases there. This research is the bill coming due for the gap between how fast apps can be built and how fast their builders learn the security model.

Why this matters

The scary part of the UpGuard findings isn’t the number 16,000. It’s that this was trivial to find. No zero-day, no sophisticated intrusion. Just databases left readable by design, discoverable by anyone who looks. The victims aren’t the platforms; they’re the ordinary people whose passport scans, private messages and plaintext passwords ended up queryable from a browser.

For US readers, the takeaway is practical. If you’ve used an AI coding tool to ship anything with a backend, your database deserves an audit: check that row-level security policies exist on every table, test what your API returns without an auth token, and treat “it works” as a very different statement from “it’s safe.” The AI built you the app in an afternoon. Securing it is the part it skipped.

FAQ

Was Supabase hacked?

No. UpGuard found no evidence of a breach at Supabase itself. The exposed databases were customer projects left publicly accessible, mostly because row-level security policies were never enabled.

How are AI coding tools involved?

Tools like Lovable, Bolt and Replit write SQL migrations directly instead of going through Supabase’s dashboard — and in that path, row-level security defaults to off. Developers who build by prompting rarely realize the lock was never engaged.

What kind of data was exposed?

Names, addresses, phone numbers, user passwords and authentication tokens, and in rare cases credit card data. Over half of the identified databases leaked personally identifiable information, according to Cybernews.

How can developers check their Supabase projects?

Audit every table for row-level security policies, test API endpoints without authentication to see what’s readable, and lock down storage bucket permissions. Supabase says it notifies affected customers when it detects exposure — but don’t wait for the email.

Sources: TechCrunch, Cybernews, Techflier