16,326 Supabase Databases Are Open, and Vibe Coding Left Them That Way

Security firm UpGuard says it found 16,326 databases hosted on Supabase that expose readable tables to anyone on the public internet. In research published September 25, the firm calls it the largest study of its kind, and it names a specific culprit for how so many ended up that way: tables created by code, often code written by AI agents, that never had row-level security switched on.

More than half of the exposed databases showed signs of personally identifiable information, according to UpGuard. A smaller share held passwords or authentication tokens, and a very small number contained what looked like plausible credit card data. TechCrunch, which reported the findings, noted that some of the leaky projects belonged to Y Combinator startups and to apps the researchers described as vibe-coded.

How UpGuard found them

The method is almost embarrassingly simple, which is part of the point. Supabase apps can be fingerprinted from the outside because their key names and database addresses sit in public JavaScript files. UpGuard started with about 300,000 unique domains showing Supabase indicators, drawn from BuiltWith technographic data and Google's Chrome UX Report dataset, then checked each for a table commonly named 'users'. Rather than pulling individual rows at scale, the team analyzed schemas to classify what kind of data each exposed database held.

That matters for how to read the 16,326 figure. It is a floor, not a census. UpGuard only probed for one common table name, so databases that leak data under other table names would not show up in the count.

What was sitting in the open

The case studies are where the abstract number turns concrete. UpGuard documented:

• An Indian adult-content subscription platform exposing 65,467 users, including identity documents, addresses, and payout account details for services such as PayPal, Payoneer and Stripe, plus more than 100,000 private messages between creators.
• A US valet service CRM with more than 100,000 customer phone numbers and roughly 78,000 license plate numbers.
• An African government consulate in France exposing about 25,000 people's personal details, including emergency housing locations.
• A Canadian immigration coaching service with nearly 5,000 records, 884 of them containing passwords stored in plain text.
• A Philippine one-time-passcode service leaking more than 100,000 SMS messages; TechCrunch described a virtual SIM farm of this kind as infrastructure used for scams and phishing.

UpGuard also found the problem is not tied to any particular business type. Ecommerce and restaurant apps were the most likely to expose personal data alongside payment integrations, and unlicensed betting platforms leaked credentials disproportionately. But the firm's broader conclusion is that exposure tracks configuration knowledge, not business model: the founders knew what they were selling, just not how their database was set up.

The default that AI agents skip

Supabase is Postgres underneath, and its access model leans on row-level security (RLS): policies that decide which rows a given user can read or write. Without RLS, the public 'anon' key that ships in every client bundle can read the whole table.

Here is the gap UpGuard describes. After a 2025 incident, tracked as CVE-2025-48757 and tied to apps built with Lovable, Supabase made RLS the default for tables created in its dashboard Table Editor. Tables created programmatically through SQL or the API do not get that default. That is exactly the path AI coding agents take. According to UpGuard, agents such as Claude Code, along with the inexperience of many vibe coders, lead to insecure configurations persisting even as Supabase ships product fixes. Secondary coverage summarizing the report also lists Cursor, Bolt and Lovable among the tools that generate raw SQL leaving RLS off.

In other words, the safety net sits in the UI, and the fastest-growing population of Supabase users rarely touches the UI.

Supabase's CISO, Bil Harmer, told TechCrunch the company treats security as never finished and wants to keep making it easier to ship securely. He also framed it as shared responsibility, with projects secure by default. The UpGuard data suggests those two statements are in tension: a default that only applies to one of several creation paths is not much of a default for users who never see that path.

Why this is bigger than one platform

UpGuard frames the finding as a repeat of history. Amazon S3 buckets and public GitHub repositories both went through long stretches of mass exposure driven by permissive defaults and huge user bases, and both eventually tightened settings. The firm's own shorthand is that leaks are the product of how easy a technology is to misconfigure multiplied by how many people use it.

Supabase's user base is now large and growing fast. Unite.AI's coverage notes the company reached a $10 billion valuation as of June 2026, and it has become the default backend for a generation of apps assembled by prompting. UpGuard also cites earlier, smaller studies pointing the same direction: one found 28% of 107 Y Combinator startups tested were leaking PII, and another found 39 of 1,072 vibe-coded apps readable via public keys.

For builders, the practical takeaway is narrow and urgent. Any table created by an agent should be checked for RLS before launch, and the anon key should be treated as fully public, because it is. For the AI coding tools, the pressure point is obvious: an agent that scaffolds a database should enable RLS and write a policy by default, not leave it as an exercise for a user who may not know it exists. For Supabase, the question is whether it extends secure defaults to every creation path, as S3 and GitHub eventually did, before the next scan finds more.