16,326 Supabase databases anyone could read: how AI coding spreads an old misconfiguration

Reading at least one table in each of 16,326 Supabase databases required no password, only the credential each website already hands its visitors. That is the tally the security firm UpGuard published on 25 September 2026 after probing roughly 300,000 domains showing signs of Supabase use. According to its report, over half of those databases showed signs of personal data, and a smaller share held passwords or authentication tokens.

Supabase is a managed backend (a PostgreSQL database, authentication and an auto-generated API) and a frequent pick for AI coding assistants asked to get an app running in a few hours.

There is no platform bug to patch. Each project's own settings decide who reads what, above all row-level security (RLS), the PostgreSQL feature that limits which rows of a table each user can see. The calendar is the reason to look now: on 30 October, Supabase will stop automatically publishing new tables to its API in existing projects, as it has done by default for new projects since 30 May. Its announcement is explicit that tables which already exist keep their current permissions and stay reachable.

How many Supabase databases are exposed?

UpGuard counted at least 16,326 Supabase databases with tables readable without a password. Its research team, led by Greg Pollock, UpGuard's Director of Research and Insights, identified Supabase sites using BuiltWith and Chrome UX Report data together with analysis of each page's JavaScript. For each one they queried a users table and, to classify the databases, inferred from the schemas what kind of data they held without reading every row. They then examined a handful of cases in depth and, where the exposure looked serious, contacted the owner.

The report describes, without naming them, cases such as these:

• A US valet parking service exposing records on more than 100,000 customers: a phone number for each, number plates for about 78,000, and visit history.
• An African government's consulate holding personal details and addresses for 25,000 people, including the emergency housing where they were staying.
• A relocation and immigration advice service for people moving to Canada, with nearly 5,000 user records, 884 of them holding a plaintext password, a figure BleepingComputer also reports.
• An Indian content platform exposing details of 65,467 users, payment information and more than 100,000 private messages.

The method has limits. Where a database had no users table, the API itself suggested the name of another readable table, but the study only covers domains that BuiltWith and the Chrome UX Report could surface, and UpGuard expects a wider search would find more. The figure is best read as a floor.

UpGuard also offers a regional reading. It credits Europe's data protection rules with pushing better practice, and finds more leaks in developing regions.

Three earlier studies reached the same diagnosis

UpGuard is not the first to get here. Between May 2025 and February 2026, three other pieces of research using different methods found the same underlying problem.

Lovable, May 2025

Researcher Matt Palmer published CVE-2025-48757, covering insufficient row-level security policies in projects generated by Lovable, a platform that builds apps from natural-language prompts. His follow-up statement lists 303 vulnerable endpoints across 170 of the 1,645 projects he examined, or 10.3%. Lovable had shipped a security scan in April; in Palmer's assessment it confirmed that policies existed without checking whether they were correct.

Escape, October 2025

Security firm Escape examined more than 5,600 public apps built with Lovable, Base44, Create.xyz, Vibe Studio and Bolt.new, going no further than an ordinary visitor could. It recorded over 2,000 vulnerabilities, more than 400 exposed secrets and 175 instances of reachable personal data, medical records and IBANs among them. One pattern it singles out is an app that ships an anonymous credential in its JavaScript and uses it to query the database API directly.

Wiz, February 2026

Cloud security firm Wiz documented a social network for AI agents, itself built with coding assistants, that carried its Supabase credential in client-side JavaScript and had no row-level security switched on. The database allowed both reads and writes and contained 1.5 million API tokens, around 35,000 email addresses and 4,060 private conversations. Once notified, the operators closed it in about three hours.

Escape also logged flaws of other kinds, but the thread running through all four is unglamorous: a database that answered whoever asked, with no sophisticated intrusion involved.

What has changed since the Lovable case?

Supabase has been tightening its defaults. According to the company, since 2025 tables created in the web dashboard switch on RLS automatically. Tables created through SQL or the API do not, unless the project has an event trigger set up to do it, and the API, according to UpGuard, is the route coding agents normally take.

On 28 April 2026 the company announced a deeper change. New tables in the public schema (the default one) stop being published automatically to the Data API or GraphQL; access has to be granted explicitly with GRANT. That became the default for new projects on 30 May and reaches existing projects on 30 October. Supabase's stated reason is that agents, command-line scripts and AI platforms now create tables too, often with no human reviewing the change.

The keys are changing too. Supabase is replacing the old anon and service_role keys with publishable (sb_publishable_) and secret (sb_secret_) keys and, per its documentation, is deprecating the older pair by the end of 2026.

The people building have changed as well. A year ago the worry was platforms aimed at people who do not write code. UpGuard now notes that Supabase is the database most recommended by Anthropic's coding agent Claude Code, and that coding agents in general tend to suggest it. A tool a department sets up this way can sit on a production database full of customer data that IT does not know exists.

Is the Supabase anon key safe to expose?

Yes, provided RLS is set up correctly: the publishable key (formerly called anon) is designed to be exposed, and what protects the data is the database's policies. In a Supabase app the browser talks directly to the database through PostgREST, a service that automatically generates a REST API from the database schema. To do so it carries the project URL and that credential, which Supabase's documentation describes as safe to put in a web page or in source code.

That credential maps to the anon role in PostgreSQL (the authenticated role comes from a signed-in user's session, not from the credential), and RLS policies decide which rows each role can see. With RLS off on a published table, the anon role reads all of it. With RLS on but a policy that admits every row for that role, the outcome is the same, and a check that only asks whether RLS is enabled will wave the table through.

Secret keys work the other way. They bypass RLS, and the documentation warns that leaking one exposes all of a project's data. Finding one in a site's JavaScript is a genuine leak: remove it and replace it promptly.

For security teams the lesson is architectural. The control sits in the database, and neither the perimeter nor client code can stand in for it. The trace of misuse shows up in the API gateway logs for as long as they are kept: requests made with the publishable credential that return whole tables.

How do you check whether a Supabase database is exposed?

It takes two tracks: find every company app that uses Supabase, then check what the API returns in each one to an anonymous visitor and to a newly registered user.

Controls that still hold

Inventory comes first. Many of these apps are shadow IT in its purest form, and finding them takes two angles. Externally, look for your organisation's domains and subdomains whose JavaScript calls Supabase projects; an external attack surface management programme can automate that part. Internally, review Supabase subscriptions paid on corporate cards and ask the teams building with AI what they have shipped.

Then enforce least privilege inside the database. For each project you find, this read-only query against the PostgreSQL system catalogue lists the public-schema tables with RLS switched off:

select schemaname, tablename from pg_tables where schemaname = 'public' and rowsecurity = false;

The query does not cover views, which in Supabase bypass RLS by default because they run with their owner's privileges, so check them separately. The security advisor in the Supabase dashboard flags these cases and some close relatives, such as overly permissive policies or sensitive columns left exposed; its advisor guide covers each check. Existing projects can move to explicit grants today, without waiting for 30 October.

A policy needs testing before anyone relies on it. The test has two halves: query the API using only what the page ships to the browser, as an anonymous visitor would, then repeat it as a freshly registered test user, because many apps allow open sign-up. Either way, the API should return only what it is meant to. That check can be built into a DevSecOps pipeline or covered in an API security audit.

Assumptions that have expired

• Treating a credential visible in front-end code as an incident in itself. If it is the publishable one, what matters is what the database gives back to whoever uses it.
• Confining review to the code an assistant writes. The configuration that opens the database comes from SQL statements the agent runs, which may never reach the repository.
• Trusting a ticked box: if the policy lets anyone read everything, having RLS switched on does not protect the table.
• Expecting the provider's change to fix the past, when tables that exist on 30 October keep their grants.

Where a supplier builds these apps on your behalf, how it controls access to its managed database belongs in your third-party risk questionnaire.

If a table was exposed, does it have to be reported?

Whether to notify depends on what the table held and on what can be shown about access. A table of personal data readable without authentication may amount to a personal data breach affecting confidentiality (see our security breach entry), and without logs proving nobody read it, the exposure itself weighs on the assessment.

In that case, Article 33 of the GDPR requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. Where the risk is high, as when passwords are exposed, Article 34 also requires telling the people affected. We have looked at how the AEPD, Spain's regulator, assessed the risk of a breach attributed to an AI agent.

Telling "exposed" apart from "accessed" depends on the API gateway and PostgREST logs, and how long Supabase keeps them depends on the plan: one day on Free, seven on Pro, 28 on Team and 90 on Enterprise. Lock the table down and export those logs at the same time.

The open question

From 30 October, new tables in the public schema will start out closed to the API in every project, and fewer fresh exposures should follow. UpGuard likens the situation to Amazon S3 and GitHub, two services with convenience-first settings that saw years of leaks. In our view, Supabase has corrected its defaults earlier in its life than either of those services, and with agents explicitly in mind.

It remains unclear how an agent will behave when the table it has just created does not show up in the API. Will it grant the narrowest access, or whatever gets the app working fastest? Until then, every GRANT an agent runs should get the same review as a permission change made by a person.

For the security risks of AI-assisted development in the enterprise, see our analysis of copilots and vibe coding; for controlling machine credentials, our guide to non-human identities.

The SQL query and configuration advice in this article are for guidance only. They draw on public Supabase and PostgreSQL documentation and on third-party research available as of 30 September 2026. Validate their effect in a test environment, and against each application's intended access model, before applying them. Exposure figures come from the studies cited and have not been independently verified by Hard2bit.