16,000 Supabase Databases Are Exposing Data to the Open Web

Security firm UpGuard found around 16,000 databases hosted on Supabase exposing some degree of personal data to the public web, TechCrunch reported on Friday.

The exposed records included publicly accessible names, addresses, phone numbers and user passwords, along with a smaller number of authentication tokens. Supabase says its projects are "secure by default."

What was exposed

UpGuard set out to measure the scale of exposure across the platform. The affected databases span ordinary apps and some that are not ordinary at all: thousands of licence plates held by a US valet service, contact details of people who used an immigration and relocation service, and a database belonging to an African government's consulate in France.

One was actively malicious. According to UpGuard, a database was being used by a virtual SIM farm to intercept text messages carrying one-time passcodes for verifying online accounts — the infrastructure of scam and phishing operations, left open to anyone who looked.

Most of the exposed datasets appear to be in the United States, but UpGuard describes it as a worldwide problem. The research builds on earlier findings that turned up exposed Supabase-hosted databases belonging to Y Combinator startups and other popular apps.

Why vibe-coded apps keep landing here

Supabase lets developers store and run databases behind web and mobile apps, and reached a $10 billion valuation this year on the back of developers hosting vibe-coded apps on it. That growth is the context for the exposure count.

TechCrunch's diagnosis is specific and worth quoting exactly: "While AI tools can be used to easily build websites and apps, the generated code can often contain security flaws, or apps might require specific configuration that the developer may be ignorant of."

That second clause is the one that bites. A generated app can be functionally correct and still ship with row-level security never switched on, because nothing in the build failed. There are widely documented cases of users misconfiguring or unknowingly exposing databases, the report notes, in some instances to the tune of millions of records each.

Supabase's position

Chief Information Security Officer Bil Harmer said the company had not seen the research, and framed security as a shared responsibility: "We provide secure defaults and tooling, and customers control how their own projects are configured." He said Supabase notifies affected customers when issues are discovered, and added: "Security at Supabase is never finished."

Both halves of that can be true at once. Secure defaults do not survive a configuration step the developer never knew existed — and when the code was generated rather than written, the odds that the step was understood go down, not up.

What to do today

If you run anything on Supabase that an AI tool helped build, the check is short and worth doing before the weekend:

• Confirm row-level security is enabled on every table holding user data, not just the ones you remember creating.
• Try reading a sensitive table with the anon key from outside your app. If rows come back, so do they for everyone else.
• Audit which keys shipped to the client. The anon key belongs there; the service-role key never does.

The failure mode in this research is not a platform breach. It is the gap between an app that works and an app that is configured — and that gap is exactly what generated code is worst at closing.