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.
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
Related on Start with Identity
- BlogCrowdStrike agrees to buy SGNL for 740 million dollars
The deal that opened 2026's consolidation wave. SGNL brings CAEP-based continuous access evaluation and just-in-time authorization to a Falcon identity business
- BlogP0 Security extends its authorization control plane to workloads and AI agents
General availability for non-human identity lifecycle management plus runtime authorization for agents, with one enforcement model that combines the invoking us
- Blog1.6 million RingCentral records leaked, and the entry point was one phone call
ShinyHunters voice-phished a RingCentral employee out of their password in July, took 623GB, and dumped 280GB after the company refused to pay. Have I Been Pwne
- CVEKeycloak authorization bypass
Keycloak failed an authorization check, so a caller could reach a resource their role should have blocked. Part of the April 2024 RHSA-2024:1868 set with CVE-20
- CVEKeycloak UMA policy privilege escalation
Keycloak's UMA policy engine checked only the first resource in a request (CWE-266). Additional resources skipped the check. A privilege escalation in user-mana
- CVESailPoint IdentityIQ role-editing authorization flaw
IdentityIQ failed to authorize role edits on all versions at disclosure (April 2026). Anyone who could reach the role-editing surface could change roles they sh