16,000 Supabase Databases Were Open to Anyone. Nobody Hacked Anything.

On September 25, UpGuard reported 16,326 Supabase databases with publicly readable tables. More than half showed signs of personal data. Some had passwords and tokens.

No one broke in. The data was readable through the front door.

What went wrong

Supabase's anon key ships in your browser code by design. Row-level security (RLS) decides what that key can read.

RLS off means anyone with your project URL and key can read the table. Nothing errors, so nobody notices.

UpGuard says many of the apps appear to be built with AI coding agents, though not in every case.

Check yours in 2 minutes

Turn on RLS and add a policy:

alter table public.profiles enable row level security;

create policy "read own profile" on public.profiles
  for select to authenticated
  using ((select auth.uid()) = user_id);

Then test as an anonymous user. You should get an empty result or an error, never rows:

curl "https://<project-ref>.supabase.co/rest/v1/profiles?select=*&limit=1" \
  -H "apikey: <anon-key>" -H "Authorization: Bearer <anon-key>"

Also keep service_role out of client code, and don't store passwords in app tables.

Same pattern, everywhere

Data rarely leaves through a hack. It leaves because an action moved it somewhere and nothing said so: a missing policy, a debug log, a paste into a random web tool.

I wrote up nine of these: Where Developer Data Actually Leaks

Have you audited RLS on your project lately?

Sources: BleepingComputer, TechCrunch