Start with Identity
News

More than 16,000 Supabase databases were readable by anyone because row-level security was missing

UpGuard found over 16,000 Supabase databases exposing readable tables with personal data, plaintext passwords and authentication tokens, caused by missing or ineffective row-level security and misused keys. Many appear to have been built with AI coding agents.

By SWI Community TeamSep 28, 2026

Researchers at UpGuard analysed about 300,000 domains showing signs of Supabase use and found more than 16,000 misconfigured databases with readable tables. The causes were missing or ineffective row-level security (RLS) policies and misuse of public keys. Exposed data included personal information, plaintext passwords, authentication tokens and, in a smaller set, card data. Examples included a US valet service with more than 100,000 customer records, a Canadian immigration service with 5,000 users and 884 plaintext passwords, a Philippine OTP service with more than 2,000 users and 100,000 SMS messages, and an African government consulate with records on 25,000 people. UpGuard says the common thread appears to be sites built by AI coding agents, while noting that was not established in every case. The report cites a figure of over 60 percent of new Supabase databases being created with AI-assisted development.

Why it matters

Nothing was hacked here, because nothing needed to be. In Supabase the anonymous key ships in the browser by design, and row-level security is the authorization layer that decides what that key can read. With RLS off or written as "allow all", authentication works perfectly and authorization does not exist, so the public key reads every row. This is the gap between authentication and authorization in its most literal form.

The plaintext passwords point to a second mistake: apps storing their own credentials in application tables beside a managed auth service such as Supabase Auth rather than using it. If you or your teams ship on Supabase, check three things: RLS enabled on every table in an exposed schema with policies that reference the signed-in user, the service_role key never present in client code, and no password or token columns in application tables at all. For AI-generated apps, make those checks part of review, since a working demo says nothing about whether authorization exists.

Source: BleepingComputer

Last reviewed By SWI Community TeamSuggest a correctionHow we research
Independent analysis. No vendor sponsorship.