Security firm UpGuard says it found 16,326 Supabase databases with tables that anyone could read, exposing personal data in more than half of them. The cause is a missing access setting, one that apps built with AI coding tools can easily skip, according to UpGuard’s research.
What happened
UpGuard checked about 300,000 domains showing signs of Supabase use. It looked for Supabase key names and database addresses in public browser code, then tested whether tables could be read without logging in. TechCrunch reported the findings on September 25, and Cybernews confirmed the 16,326 figure the next day. UpGuard names AI coding tools such as Claude Code and Codex, and vibe-coding platforms such as Lovable and Replit, among the ways apps get built this way.
Over half of the exposed databases showed signs of personal information. A smaller share exposed passwords or authentication tokens, and a very small number held what looked like card data. Examples UpGuard described include a US valet service with more than 100,000 customer records, an African consulate database with personal details and addresses for about 25,000 people, and a Canadian immigration coaching service where 884 of nearly 5,000 records held a plaintext password.
The mistake behind it
Supabase protects tables with row level security (RLS), rules that decide who can read or change each row. UpGuard describes three recurring problems:
- Tables with no RLS at all, so anyone could query them
- RLS policies that did not restrict access enough
- Public keys placed in browser code and treated as if they were secret
UpGuard says RLS is on by default for tables created in Supabase’s Table Editor, but not for tables created through the API, which is how coding agents usually work.
Supabase’s chief information security officer, Bil Harmer, told TechCrunch the company had not seen the research, that its projects are “secure by default,” and that security is a shared responsibility with customers.
What to do
UpGuard’s write-up reports findings rather than a fix list. The steps below are our analysis, based on standard hardening practice, not UpGuard’s advice. For developers:
- Enable RLS on every table in the public schema.
- Write policies so users can reach only their own rows.
- Keep secret and service-role keys out of browser code.
- Review every table an AI coding tool created, and test access while logged out.
- Do not store passwords in plaintext.
For users: if an app you use may have stored your password, change it and any account where you reused it, and turn on two-factor authentication where offered.
What we still do not know
UpGuard has not published a full list of affected sites. It is not confirmed how many of the exposed databases have since been fixed, or whether anyone other than researchers accessed the data.
Sources: UpGuard research write-up (October 14, 2026 page date); TechCrunch (September 25, 2026); Cybernews (September 26, 2026).
Leave a Reply