The scan
The security firm UpGuard published research on Friday that scanned roughly 300,000 domains showing signs of Supabase, drawn from BuiltWith technographic data and Chrome UX Report datasets on BigQuery, and queried each one for a users table.
It found 16,326 databases where at least some tables could be read by anyone. More than half showed indicators of personally identifiable information. Smaller numbers showed passwords or authentication tokens, and a very small number showed what looked like card data.
What was in them
The examples are specific. An Indian platform exposed 65,467 users with names, emails, dates of birth, driving licence, passport and Aadhaar details, plus financial information. A one-time-passcode service in the Philippines exposed more than 2,000 users and over 100,000 SMS messages, including the codes themselves. A US valet parking service exposed more than 100,000 customers with phone numbers, emails and licence plates.
An African government’s consulate exposed 25,000 records with addresses belonging to vulnerable populations. A Canadian immigration and relocation service exposed 5,000 records, 884 of them with passwords stored in plain text. UpGuard also found infrastructure tied to a virtual SIM farm used to intercept the one-time codes that verify online accounts — the supply side of account-takeover fraud, sitting open.
Most of the exposed datasets appear to be in the United States, but UpGuard describes the problem as worldwide, and notes that regions with stronger data protection practice showed better results.
The default that is not a default
The mechanism UpGuard identifies is narrow and specific. “Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default,” it writes. Row-level security is the control that decides which rows a given caller may read; without it, a table reachable from the public internet is readable.
That matters because of who is creating the tables. Supabase reached a $10 billion valuation earlier this year on the back of developers hosting vibe-coded applications, as TechCrunch notes. A person directing a coding agent is not necessarily someone who knows what row-level security is, let alone that the path their agent took skipped it.
Supabase’s answer
Supabase chief information security officer Bil Harmer told TechCrunch the company had not seen the research, and that its projects are “secure by default”. He framed security as a shared responsibility: “We provide secure defaults and tooling, and customers control how their own projects are configured,” and said the company notifies affected customers when it finds problems.
“Security at Supabase is never finished. We care deeply about getting it right, and we’ll keep making it easier for every developer to ship securely,” Harmer said.
Both statements can be true at once, which is the uncomfortable part. The dashboard path may well be secure by default while the API path is not, and the API path is the one the agents use.
What would close it
The fix is not a mystery: enable row-level security on tables created through the API, or refuse to serve them publicly until a policy exists. That is a platform decision rather than a customer one, and it is the decision worth watching for. Until it is made, the count is a floor, not a ceiling — UpGuard looked for one table name, on domains it could identify, at one moment.
