16,326 Supabase Databases Are Readable by Anyone. The Common Thread Is a Table an Agent Created

Security firm UpGuard published research on 25 September identifying 16,326 Supabase-backed databases whose tables can be read by anyone on the open internet. More than half hold personal information about real people: names, dates of birth, email addresses, phone numbers, physical addresses. A smaller share hold plain-text passwords and authentication tokens.

Nothing was broken into. There is no vulnerability, no patch, no CVE. Every one of those databases is doing exactly what its configuration tells it to do. That is what makes this something other than another breach story — the failure is systemic, and it is a default.

The configuration at the centre of it

Supabase gives every project a hosted Postgres database with a REST interface in front of it. The client-side code running in a visitor's browser carries a key Supabase calls the anon key. It is meant to be public. It identifies the project and nothing more, and Supabase documents it that way.

What stops that public key from functioning as a master key is row-level security, the Postgres feature that decides which rows a given role may see. With RLS enabled and a policy written, an anonymous visitor sees only what the policy allows. With RLS off, a table in an exposed schema is readable by whoever asks for it — Supabase's own documentation states this plainly.

UpGuard's argument is that the two halves of that arrangement have drifted apart. Supabase enables RLS by default for tables created through its Table Editor interface. Tables created programmatically through the API do not inherit the same default — and programmatic creation is how coding agents build schemas.

"Supabase is now in the position of mass adoption where insecure config patterns lead to systemic data exposures," writes Greg Pollock, UpGuard's director of research and insights and the report's author.

What is actually sitting in them

UpGuard says it analysed roughly 300,000 domains carrying Supabase indicators, and assessed data types without reading databases in full. The cases it names have nothing in common except their stack.

A SIM farm and a consulate are not the same kind of organisation, do not face the same adversaries, and do not have the same idea of what a secret is. They made the same mistake anyway. Pollock's framing of why is the sharpest line in the report:

"The security settings are invariant to business type because the humans ... do not understand their database's configuration."

The part that is about AI

It is tempting to file this under developer carelessness and move on. The more useful reading is about who — or what — is now writing the schema.

An AI coding agent asked to build an app will create tables through the API, because that is the interface available to it. It will wire up the client with the anon key, because that is what the documentation says to do. Both steps are correct in isolation. The step that does not happen is the one that was never in the prompt: deciding, table by table, who should be allowed to read this. A human building the same app in the dashboard would have been handed a safe default. The machine takes the other path.

This is the shape of a whole category of problem arriving now. Security defaults were designed around a human sitting in a console, seeing a warning, and clicking something. Agents do not sit in consoles. When the safe default lives in the UI rather than in the database, automation routes around it — at the speed and volume automation works at.

What Supabase says

Bil Harmer, Supabase's chief information security officer, told TechCrunch that "our projects are secure by default" and described security as a shared responsibility between the company and its customers. "We care deeply about getting it right, and we'll keep making it easier for every developer to ship securely," he said.

Both things can be true at once. The defaults are sound on the path Supabase designed for people. The exposure is on the path machines take, and 16,326 databases is not a figure that survives being called a user-education problem.

If you run one of these

The check is whether RLS is enabled on every table in an exposed schema. Supabase's documentation is explicit that enabling RLS alone is not sufficient: the automatic privileges granted to the anon and authenticated roles have to be revoked as well. Unprotected tables are flagged in the project dashboard, and that list is the place to start.

Start with the tables nobody remembers creating. On current evidence, those are the ones an agent made.

UpGuard says it notified the owners of the significant exposures it identified. For the people whose names, addresses and passwords are in those tables, that notification is the only control they ever had.

Sources: UpGuard — Everything, Everywhere: Systemic Data Exposure in Supabase Apps · TechCrunch — Some Supabase customers are publicly exposing reams of people's data to the web · Supabase documentation — Row Level Security · Unite.AI — UpGuard Study Finds 16,326 Supabase Databases Exposing Readable Tables