The scan covered roughly 300,000 domains; more than half the readable databases showed indicators of personal information as Supabase changes its defaults.
By [RuntimeWire Staff](https://runtimewire.com/author/runtimewire-staff)
· Published
Primary source: [TechCrunch](https://techcrunch.com/2026/09/25/some-supabase-customers-are-publicly-exposing-reams-of-peoples-data-to-the-web/)
Why it matters #
UpGuard's scan links the speed of AI-assisted app building to a measurable database-access problem. Supabase's new-table defaults are changing, but customers still need to secure existing tables and configure access policies correctly.
Cybersecurity firm UpGuard says it found 16,326 Supabase databases with readable tables after scanning roughly 300,000 domains showing signs of Supabase use. More than half had indicators of personal information. The research, published September 25th, puts a hard number on a risk that follows the platform's rapid adoption by developers building apps with AI tools. For Supabase co-founder and CEO Paul Copplestone, the findings test a founding idea: make databases easier for developers to use.
Copplestone has described how he built a Postgres real-time engine at a previous company after running into limits with Firebase, then asked his friend Ant Wilson to help build an open-source company around the idea. Supabase joined Y Combinator's Summer 2020 batch. Its platform packages Postgres with authentication, storage, realtime features and APIs that let applications reach database tables.
What the scan counted
UpGuard began with about 300,000 domains where it detected signs of Supabase use, then tested for a commonly named "users" table. Its researchers identified 16,326 databases where at least some tables could be read. Rather than inspect every record, the team used table names and schemas to assess what data could be present. More than half showed indicators of personally identifiable information; smaller numbers showed indicators of passwords or authentication tokens. UpGuard told TechCrunch that about 16,000 databases had some degree of personal data exposed.
The figure counts readable databases; it does not count people or records. The study does not establish how many individual records were exposed, when each database first became readable, or how long any exposure lasted. The scan shows broad reachability and the kinds of information that may have been present, while the researchers' schema-based approach does not verify every row in every database.
The examples reported by TechCrunch show the range of potential consequences. UpGuard said it found names, addresses and phone numbers, along with databases linked to private conversations on an Indian adult streaming site, a U.S. valet service's license plates and an immigration and relocation service's contact details. It also described a database associated with a consulate of an African government in France and another used by a virtual SIM service to handle one-time passcodes. The findings are not evidence that every exposed database was misused.
Supabase changes defaults for new tables
The platform's automatically generated Data API lets applications query tables over HTTP. UpGuard says many exposures stemmed from absent or weak Row Level Security (RLS) policies, or tables that remained publicly queryable. An API key placed in client-side code is not necessarily a secret credential; the key's presence does not by itself establish a vulnerability. The access rules around a table determine what a user can retrieve.
Supabase has begun changing defaults. In its April 28th changelog entry, Supabase said new projects could opt out of automatically exposing new tables in the public schema through its Data and GraphQL APIs. On May 30th, the new behavior started to become the default for new projects in a gradual rollout over several weeks. Supabase scheduled enforcement for existing projects for October 30th. The change concerns default grants for new tables; Supabase says existing tables keep their current grants. It therefore cannot be treated as a fix for every table UpGuard found readable.
UpGuard also says tables created programmatically, the route commonly used by coding agents, do not enable RLS by default. Supabase's change to default grants addresses whether the API can reach new tables; it does not remove the need to configure row-level access when a table is deliberately exposed. Developers still need to decide which roles can read or write which records and test those rules before putting real user data behind an app.
Supabase Chief Information Security Officer Bil Harmer told TechCrunch that Supabase had not seen UpGuard's research and described projects as "secure by default." He said security is shared between Supabase and customers, who control how projects are configured, and that Supabase notifies affected customers when it discovers security issues. He also said Supabase would keep working to make secure deployment easier.
Supabase's June Series F announcement said the company had nearly 10 million developers and that database launches had grown 600% year over year; those are company-reported figures, not independent measures of how securely those apps were configured. The round, a $500 million financing led by GIC at a $10 billion pre-money valuation, gave Supabase room to invest in the platform. The exposure findings put security defaults and onboarding on that investment list alongside scale and reliability.
RuntimeWire previously covered Supabase's rollout of Grafana monitoring across its plans, a move aimed at making infrastructure more visible to customers. Monitoring can help operators spot operational problems; access policies determine whether user data is exposed in the first place. For Copplestone and Wilson's original open-source proposition to keep working at AI-app scale, the platform has to make the safe path as easy to follow as the fast one.