Exposed Supabase Databases: What the UpGuard Finding Means
UpGuard found about 16,000 Supabase databases leaking user data. What it found, what Supabase said, and what to check in your own AI-built app today.
Security firm UpGuard found about 16,000 Supabase databases publicly exposing personal data, including names, addresses, phone numbers, passwords, and authentication tokens, according to TechCrunch's report of 25 September 2026. The reported cause is configuration, not a flaw in the platform. If you built an app on Supabase, with or without AI help, the fix is a check you can run in an afternoon.
This is an analysis a week after the story broke, so it focuses on what is known and what you can verify yourself.
What was found
According to TechCrunch's coverage, UpGuard's examples included private conversations from an adult streaming site, license plates collected by a US valet service, contact details from an immigration services firm, and data from an African government consulate. The same coverage describes the exposed data as including names, addresses, phone numbers, passwords, and authentication tokens.
Several outlets gave the count more precisely as 16,326 databases with publicly readable tables. We could not find UpGuard's own write-up while researching this post, so treat that figure as reported by secondary coverage and the rounded "about 16,000" as the safer number.
What Supabase said
TechCrunch quotes Supabase's chief information security officer, Bil Harmer, saying projects are "secure by default" and that security is a shared responsibility: "We provide secure defaults and tooling, and customers control how their own projects are configured."
TechCrunch's article attributes the exposures to misconfiguration and improper security rather than a specific technical flaw, and notes that vibe-coded and AI-generated apps can spill users' data when they are not configured or secured properly.
Why row level security keeps coming up
Supabase exposes your tables to the browser through an API, and the key your front end uses is meant to be public. What stops a stranger from reading everything is row level security, or RLS, which decides which rows each role may read or change.
Supabase's own documentation is direct about this. Its row level security guide says that once RLS is enabled, "no data is accessible through the API when using a publishable key, until you create policies." Its guide to securing the Data API warns that tables exposed through the Data API without RLS "can be accessed by any role with matching grants."
Read those together and the failure mode is clear. A table with no RLS, reachable with the public key, is readable by anyone who finds the project URL. A separate rule from the docs matters just as much: the service_role key bypasses RLS and must stay on the server.
What this does and does not say about AI-built apps
TechCrunch's framing links the exposures to vibe-coded apps, and that is plausible: a generated app that "works" in the preview gives no visible sign that a table is open to the world. But the evidence in the public coverage is about misconfigured projects, not about how each one was built. Hand-written apps can leave the same door open.
The lesson is not "avoid AI builders". It is that a working app and a safe app are different tests, and only one of them shows up on screen.
What to do this week
Open your project and list every table the API can reach.
Confirm RLS is enabled on each one.
Confirm every table has policies written for the roles that should read it, and none for roles that should not.
Make sure the service role key is not in your front-end code or any public repository.
Test from the outside, as an anonymous visitor. The step-by-step method is in our guide to checking whether your AI-built app exposes user data.
If you find an exposure, treat it like a vendor breach and work through rotation and notification, rather than quietly closing the table. For the habit that prevents most of this, see how to review AI-generated code before you ship it, and for secrets handling, environment variables and secrets in an AI-built app.
FAQ
How many Supabase databases were exposed?
UpGuard's research, as reported by TechCrunch, found about 16,000 databases publicly exposing personal information. Some outlets report 16,326.
Was this a Supabase hack?
No public coverage describes a breach of Supabase itself. Supabase's CISO characterized the exposures as customer configuration, and TechCrunch attributes them to misconfiguration and improper security.
What is row level security?
It is a Postgres feature that restricts which rows a given role can read or change. Supabase's documentation says that with RLS enabled and no policies, no data is accessible through the API with a publishable key.
Is my app affected?
Only a check of your own project can tell you. If any table reachable by the public key has no RLS, anyone with your project URL may be able to read it.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
