16,326 Databases Leaked. The Bug Was a Default, Not a Hack.

Sixteen thousand three hundred twenty-six Supabase databases were sitting open on the public internet. Anyone with a browser could read them. Zero exploits, zero credentials stolen, zero clever hacking required.

That number comes from UpGuard, published September 25. It's not a breach in the way we usually mean the word — nobody broke in. The data was just... there, because a default flips the wrong way depending on how you created the table. And the way that default flips wrong is exactly the path your AI coding tool takes by default.

If you or your dev shipped an app on Supabase with help from an AI coding tool, this is worth twenty minutes of your morning.

What UpGuard actually found

UpGuard fingerprinted roughly 300,000 domains for Supabase usage, then queried each one for a users table. 16,326 databases answered with readable data. More than half showed personally identifiable information — names, emails, phone numbers, addresses. A smaller slice had passwords or auth tokens exposed. A very small slice had usable payment data.

The specific exposures are the part that makes this real instead of abstract. A U.S. valet service leaked phone numbers for over 100,000 customers, names and emails for 43,000, and license plate numbers for 78,000. A Canadian immigration-coaching service leaked roughly 5,000 records, 884 of them with plain-text passwords. An Indian adult-content platform leaked 65,467 users' driver's licenses, passports, and financial data. An African consulate in France leaked 25,000 people's personal records alongside emergency housing locations. [1][2]

None of these companies got hacked. Their databases were configured to answer anyone who asked.

The default that's on in one place and off in the other

Here's the mechanism, and it's the part that should actually change what you do this week: Supabase's dashboard Table Editor turns on Row Level Security by default. Create a table by clicking through the UI, and nothing is readable until you write a policy that says otherwise. Deny-all until proven otherwise — the correct posture.

Create that same table through raw SQL, a migration file, or the API — "which is how coding agents interact with Supabase," in UpGuard's words — and RLS is off. No policy needed to read it. Just the anon key, which ships in your client-side code by design, because that's how the app is supposed to work. [1]

A coding agent writing your schema through the API or a migration file takes the path where the safe default doesn't apply — and most agents write schema exactly that way, because that's the fast path. This isn't new: a developer reported a near-identical Supabase misconfiguration tied to the vibe-coding platform Lovable back in March 2025, tracked as CVE-2025-48757. [1] The pattern has been visible for a year and a half. It's just bigger now.

Source: UpGuard — Everything Everywhere: Systemic Data Exposure in Supabase Apps

Look at that table by industry and the SMB angle stops being theoretical. Ecommerce and retail lead on nearly every column — names, emails, phone numbers, payment data. Food and restaurant isn't far behind. This isn't a story about enterprise breaches. It's a story about the exact size of business that hires an agency, vibe-codes an MVP over a weekend, and ships.

flowchart TD
  Start([New Supabase table]) --> Q{Created how?}
  Q -->|Dashboard Table Editor| RLSOn[RLS ON by default]
  Q -->|SQL, migration, or API —<br/>how coding agents work| RLSOff[RLS OFF by default]
  RLSOn --> Safe[Deny-all until you<br/>write a policy]
  RLSOff --> Agent[Coding agents write<br/>schema this way by default]
  Agent --> Ship[App ships. Demo works.<br/>Nobody re-checks the table.]
  Ship --> Exposed[Anyone with the public<br/>anon key reads every row]

"Secure by default" is doing a lot of work in that sentence

Supabase's CISO, Bil Harmer, told TechCrunch the company hadn't seen UpGuard's research yet, that Supabase projects are "secure by default," and that "we provide secure defaults and tooling, and customers control how their own projects are configured." [2]

That's technically true and still a dodge. "Secure by default" is only true for the one creation path a non-technical founder is likely to use directly — the dashboard. The path your coding agent uses by default is the one where the default is insecure. Shared responsibility is a fair framing for a security incident caused by a customer's choice. It's a weaker framing for a security posture that changes based on which tool wrote the SQL, with no warning either way.

I'm not picking on Supabase specifically here — this is the shape of the problem with multi-tenant SaaS built fast, not a Supabase-only flaw. Any backend where an agent can write schema without a human reviewing the security implications has this exposure waiting somewhere. Supabase just happens to be the most popular place vibe-coding tools point their SQL.

A misconfigured database isn't a hack. It's a default nobody checked, because the tool that wrote the schema never told them to.

The audit I'd run before your next launch

This isn't complicated. It's twenty minutes with the SQL editor open, and it's exactly what I check first on every engagement that touches a client's backend.

If your app has been live for more than a month and nobody's run that first query, you don't know your exposure. That's not an insult — it's the default state of most fast-shipped SaaS right now. It's the same blind spot behind every AI vendor-trust gap SMBs don't check: the tool works, so nobody asks what it's quietly doing underneath.

This isn't a Supabase problem

It's an agent-writes-schema problem, and Supabase just has the market share to make it visible first. Every backend-as-a-service platform that lets a coding agent create tables programmatically has some version of this gap — a safe default for the path humans use, and a permissive one for the path agents use, because agents talk to APIs and humans click through dashboards.

The fix isn't "don't use AI coding tools." It's "don't trust the demo working as proof the database is locked down." A demo that returns the right data to you, logged in as the test user, tells you nothing about what it returns to a stranger with your anon key and no login at all.

The short version

• UpGuard found 16,326 Supabase databases publicly readable — zero hacking required, just an unset default
• The cause: Supabase's dashboard enables Row Level Security by default; SQL, migrations, and API calls — how coding agents write schema — don't
• The pattern isn't new — a near-identical gap tied to the platform Lovable was reported back in March 2025; this report shows how much bigger it's gotten
• Ecommerce, retail, and food/restaurant businesses show among the highest rates of exposed PII by industry — this is an SMB story, not an enterprise one
• Run the five-check audit above before your next launch, and again after every AI-authored schema change
• "Secure by default" only protects the path a human clicks through — verify the path your agent wrote instead of trusting the demo

Sources

[1] UpGuard — Everything Everywhere: Systemic Data Exposure in Supabase Apps — September 25, 2026 [2] TechCrunch — Some Supabase customers are publicly exposing reams of people's data to the web — September 25, 2026 [3] Supabase — Row Level Security documentation

If your team shipped fast on Supabase, Firebase, or any backend-as-a-service and nobody's run a security audit since, that's exactly the gap I check first on a new engagement. Book a 15-minute call and I'll tell you honestly what's exposed and what it takes to fix it — same audit-first approach that cut The Hub's monthly software cost 60% by finding what nobody had checked in years.