Security firm UpGuard published research yesterday (September 25) finding 16,326 Supabase databases with publicly readable tables — no authentication required, no exploit needed. The data inside includes names, addresses, phone numbers, passwords, authentication tokens, and in some cases plausible credit card data. This is not a breach of Supabase itself. It is a developer misconfiguration crisis playing out at industrial scale, and AI vibe-coding tools are systematically making it worse.
What Is Actually in Those Open Supabase Databases #
UpGuard researcher Greg Pollock led the study — the largest of its kind — scanning roughly 300,000 domains where Supabase usage was fingerprinted. Of those, 16,326 had at least one table readable by anyone who knew the project URL. More than half contained personally identifiable information. The documented cases are not toy projects: according to TechCrunch’s coverage of the UpGuard findings, a U.S. valet service exposed 78,000 license plates, 100,000 customer phone numbers, and 665 employee records with push notification tokens. An immigration coaching service leaked nearly 5,000 records, including 884 plain-text passwords. An African consulate operating in France exposed 25,000 records with emergency housing locations for migrants.
As Pollock put it: “Data leaks are the multiplicative product of a technology’s ease of misconfiguration and the size of its user base.” Supabase’s ease and its explosive growth — the platform hit a $10 billion valuation in June 2026 — have made it simultaneously one of the most powerful developer tools and one of the most exposed attack surfaces in backend infrastructure.
The Row Level Security Gap AI Tools Keep Falling Into #
The root cause is specific and fixable. Supabase tables created through the Dashboard’s Table Editor have Row Level Security (RLS) enabled by default, following a 2025 security patch. Tables created via SQL, API calls, or migration files — the path taken by every AI coding agent and vibe-coding tool that scaffolds a Supabase schema — do not get RLS by default. According to UpGuard’s full research report, that gap is what 16,326 open databases represent.
Supabase is “the database product most recommended by Claude Code.” When an AI tool like Claude Code, Bolt, or Cursor generates a Supabase schema, it writes SQL. That SQL creates tables without RLS. Every table is then world-readable via a standard GET request to the project’s REST endpoint. The developer never touched the Dashboard; the default safety net never triggered. Securing an existing table takes two statements, per Supabase’s official security documentation:
ALTER TABLE users ENABLE ROW LEVEL SECURITY;
CREATE POLICY "users can read own data"
ON users FOR SELECT
USING (auth.uid() = id);
The catch: enabling RLS without adding policies defaults to deny-all, which breaks the app. Developers who enable RLS and skip the policy step end up locking out legitimate users. The fix is straightforward but requires intentionality that AI-generated scaffolding does not supply.
Related: Rogue AI Agents Are Stealing Your CI/CD Credentials
What Supabase Says — and the October 30 Deadline #
Supabase CISO Bil Harmer responded to UpGuard’s findings by framing it as shared responsibility: “Supabase provides secure defaults and tooling, and customers control how their own projects are configured.” That framing is technically accurate. However, it is doing a lot of heavy lifting when 16,326 production databases contradict the “secure by default” headline.
The company has moved. On May 30, 2026, Supabase updated its defaults so new tables no longer automatically expose to the public schema. More urgently, per Runtimewire’s analysis of the enforcement timeline, the company scheduled enforcement for existing projects by October 30, 2026 — four days from now. If your project created tables via API or SQL before May 2026, audit your RLS configuration before that deadline. Supabase’s Security Advisor, available under Dashboard → Project Settings, lists tables with RLS disabled and flags missing policies.
Key Takeaways #
- 16,326 Supabase databases are publicly readable as of September 25, 2026 — production apps with real user data, not sandboxes
- The cause: tables created via SQL or API (the AI-agent path) do not enable Row Level Security by default, unlike the Dashboard’s Table Editor
- AI vibe-coding tools have multiplied this misconfiguration at scale; this UpGuard study is 10x larger than all prior research combined
- Supabase’s October 30 enforcement deadline for existing projects is four days away — run the Security Advisor now
- The fix is two SQL statements; test in staging first, since enabling RLS without policies locks out all access by default