Supabase's fix for the 16,326 exposed databases lands October 30 — and leaves all 16,326 exposed

On September 25, 2026, UpGuard published research identifying 16,326 Supabase databases whose tables could be read by anyone on the internet, drawn from roughly 300,000 domains it screened for Supabase usage. The report's framing — that AI coding agents create these tables through an API path where Row Level Security is off by default — is the part worth dwelling on. What almost no coverage noted is that Supabase diagnosed and began fixing that exact default five months before the report landed, and that the fix, by design, does nothing for the 16,326 databases already exposed.

The short version

Supabase is a hosted Postgres platform with a feature that makes it unusually attractive to AI coding agents: a REST and GraphQL "Data API" that turns database tables into web-callable endpoints automatically. Your frontend talks to the database directly using a publishable key that ships inside the browser JavaScript. That key is meant to be public. The thing standing between it and your data is Row Level Security (RLS) — Postgres policies that decide which rows a given caller may see.

If RLS is not enabled on a table that the Data API exposes, anyone who reads your JavaScript, extracts the project URL and the publishable key, and asks politely gets the table. No exploit, no vulnerability, no CVE. The platform is doing precisely what it was configured to do.

UpGuard's contribution is scale. Its researchers fingerprinted Supabase projects from public JavaScript, then checked whether tables answered. 16,326 did. Over half had schemas suggesting they held personal data. The named examples are grim: an Indian adult-content platform with 65,467 user records including Aadhaar numbers, PAN cards, passport and driver's licence details plus more than 100,000 private messages; a US valet service with over 100,000 customer records and 78,000 licence plates; an African consulate with 25,000 government personnel records; a Canadian immigration consultancy with roughly 5,000 clients and 884 passwords stored in plaintext.

The AI angle is the mechanism of propagation. Tables created by hand in Supabase's web UI have had RLS switched on by default since March 2025. Tables created programmatically through the API — which is how a coding agent works — did not.

Timeline

• March 2025 — Researcher Matt Turner reports widespread RLS misconfiguration in Supabase databases created by the vibe-coding platform Lovable; it becomes CVE-2025-48757. UpGuard cites this as the first at-scale account.
• After March 2025 — Supabase enables RLS by default for tables created through its Table Editor UI. Programmatic creation via the API is not changed.
• February 2, 2026 — Wiz publishes its analysis of Moltbook, an AI-agent social network, whose misconfigured Supabase database exposed around 35,000 email addresses and 1.5 million API keys. Wiz found the credentials in client-side JavaScript.
• April 9, 2026 — Supabase publishes "AI Agents Know About Supabase. They Don't Always Use It Right." by Pedro Rodrigues, and ships an open-source "Agent Skills" instruction set to stop agents shipping insecure configurations.
• April 28, 2026 — Supabase announces a breaking change: tables in the public schema will no longer be exposed to the Data and GraphQL APIs automatically. An opt-in toggle appears at project creation.
• May 30, 2026 — The new behaviour becomes the default for all newly created projects.
• June 2026 — Supabase reaches a reported $10 billion valuation.
• September 25, 2026 — UpGuard publishes "Everything Everywhere: Systemic Data Exposure in Supabase Apps". TechCrunch and BleepingComputer cover it the same day; Supabase's CISO responds to TechCrunch.
• October 30, 2026 — Scheduled: the grants change reaches all existing projects.

What we know

The count and the method. UpGuard's Greg Pollock, the company's Director of Research and Insights, writes that the team "identified 16,326 databases exposing readable tables" after screening around 300,000 domains carrying Supabase indicators, using Builtwith and Chrome UX Report data. Crucially, the team did not read everything it could have: "we used the table schemas to assess the types of data potentially exposed in each rather than trying to read every row." The headline data-sensitivity figure follows from that choice — "Over half of the databases had indicators of some PII." That is a statement about column names and table structures, not a verified count of exposed personal records. UpGuard says that "in the cases where we determined a significant exposure, UpGuard notified the application owners."

The default that differs by creation path. The report states the technical crux plainly: "Tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default." It pairs this with the acknowledgement that "Supabase has made product changes to implement RLS by default for tables created in the Table Editor UI" — leaving the agent path as the gap.

Supabase's position. Chief Information Security Officer Bil Harmer told TechCrunch: "We provide secure defaults and tooling, and customers control how their own projects are configured," describing security as a shared responsibility and saying the company notifies affected customers when it finds problems.

Supabase said much of this first, in April. The company's own April 9, 2026 post is a franker document than the vendor statement. It concedes that "knowing about Supabase and using it correctly are two different things," and lists what agents get wrong: skipping RLS on exposed schemas; creating views without security_invoker = true, which the post says "silently bypasses RLS"; using user-editable user_metadata for authorisation decisions; and exposing service_role keys — the keys that bypass RLS entirely — in frontend environment variables. Supabase's remedy is roughly a hundred lines of instructions in a SKILL.md, installable via npx skills add supabase/agent-skills and supporting Claude Code, Codex, GitHub Copilot and Cursor.

Supabase's own numbers on how well that works. Across six test scenarios, the company reports pass rates rising from 50% to 67% for Claude Code on Opus, 58% to 71% on Sonnet, 71% to 88% for Codex on GPT-5.4, and 63% to 71% on GPT-5.4 Mini. These are Supabase's own measurements on its own scenario set, not independent evaluation.

The structural fix, and its limit. The April 28, 2026 changelog removes automatic Data API exposure: "new tables you create in public schema require an explicit opt-in (via a Postgres grant) before the Data API can see them." Grants are a distinct layer from RLS — as Supabase's documentation puts it, grants "control whether a role can access a table at all, while RLS controls which rows that role can see." The rollout reaches existing projects on October 30, 2026. But the changelog is explicit about what that does not touch: "Existing tables are not affected in your project, they keep their current grants and stay reachable."

Technical analysis

The root cause here is not a bug in Supabase and not a bug in any model. It is a mismatch between two default behaviours that were each individually reasonable.

Supabase's Data API exists to remove a tier. Instead of writing a backend that holds credentials and mediates queries, you let the browser talk to Postgres through a generated API and enforce authorisation in the database. For that design to be safe, RLS must be non-optional — it is the entire authorisation layer. The design assumed that whoever created a table understood they had just published an endpoint.

That assumption held tolerably while table creation was a human act in a UI that could nag you. It broke when the dominant table-creation path became an agent issuing SQL through an API, because the API path inherited Postgres's own defaults rather than the UI's opinionated ones. An agent writing create table users (...) has done something that looks, in every textbook, completely unremarkable. In this platform it also published the table.

Our assessment: the novel element is not that AI-generated code contains flaws. It is that agents industrialise a single configuration decision across an enormous number of independent deployments. Human developers misconfigure in a scattered, idiosyncratic distribution; you get a long tail of different mistakes. An agent working from a stable prior produces the same mistake, at volume, across unrelated organisations that share no code, no staff and no infrastructure. UpGuard's own framing captures the economics — "Data leaks are the multiplicative product of a technology's ease of misconfiguration and the size of its user base" — but agents change the first term qualitatively, by making a platform's sharp edge get touched with near-perfect consistency.

Why the controls failed is worth stating separately for each control that might plausibly have caught this:

• Secret scanning found nothing, correctly. The publishable key is not a secret. Every scanner in the industry is tuned to ignore it. The sensitive thing was the absence of a policy in a database, which no code scanner sees.
• Perimeter and WAF controls are irrelevant. Requests come from legitimate clients to a legitimate endpoint with a legitimate key.
• Nothing was anomalous to detect. An unauthenticated read of a table the platform was told to expose is, to logs and to anomaly detection, an ordinary application request.
• The one control that works is a database-level assertion — RLS enabled and policies present on every table reachable through the API — and it lives in a place most application security programmes do not inspect.

Supabase's two interventions attack different parts of this. The Agent Skill tries to fix the agent's prior: give the model current, explicit instructions so it stops relying on training data. The grants change tries to fix the platform, by making exposure an affirmative act rather than a side effect. The second is far more robust, because it does not depend on the agent being correct — and notably, the changelog asks agents to "adopt the Supabase agent skill, which includes the grants step," meaning the platform fix and the agent fix are designed to work together.

But both are forward-looking, and this is the point the coverage missed. On October 30, 2026, the grants change arrives at existing projects and changes the default for new tables only. Every one of the 16,326 databases UpGuard found stays exactly as readable as it was, because their tables keep the grants they already have. There is no sweep, no forced remediation, no mass notification. The installed base is remediated one owner at a time, by owners who in many cases do not know they run a database.

What remains unclear

• How many of the 16,326 were actually built by AI agents? UpGuard does not say. The report asserts the mechanism — "these sites are created by AI coding agents and the humans are unaware of the configuration" — but publishes no proportion, and its methodology (deliberately targeting standalone domains rather than apps carrying vibe-coding platform watermarks) does not distinguish AI-built from hand-built. BleepingComputer's account attributes to UpGuard a figure of more than 60% of newly created databases showing AI-assisted involvement; we could not locate that figure in the report's text on repeated readings, and we flag it as unverified rather than repeat it as a finding. The same article notes UpGuard's analysis "does not establish that every affected site was built using an AI coding agent."
• "The database product most recommended by Claude Code." UpGuard states this and builds part of its argument on it, but offers no measurement or citation. Treat it as the author's characterisation.
• How much personal data was really exposed. Schema indicators are not reads. "Over half had indicators of some PII" is a reasonable proxy and an honest one, but the true figure could sit meaningfully either side of it.
• Whether Supabase received advance notice. UpGuard says it notified application owners where exposure was significant. The report does not state whether Supabase was told before publication, and Supabase's public comment does not say either.
• What Supabase will do about the existing 16,326. Harmer says customers are notified when issues are found. Neither the company nor the changelog addresses whether the known-exposed population will be contacted, or whether anything beyond the October 30 default change is planned.
• Whether the grants change survives contact with agents. If an agent's table-creation template simply adds a grant alongside create table — which is exactly what it must do for the app to work — the exposure returns unless RLS lands in the same template. Supabase's skill covers both steps. Agents not using it are an open question.

Lessons and what to do

For security teams. Add a class of asset you probably do not track: databases published directly to the internet by frontend code. Find them the way the researchers did — read your own public JavaScript bundles for backend URLs and publishable keys, then ask whether every table those keys can reach has RLS enabled and policies defined. For Supabase specifically, check the platform's own Advisors and the Data API settings for every project, including ones nobody claims to own. Treat "has RLS enabled with at least one policy" as an assertable control with an owner, not documentation.

For AI builders. The lesson is not "don't use agents." It is that an agent's defaults become your organisation's defaults, replicated perfectly. Pin security-relevant configuration in something the agent must read — Supabase's own Agent Skill is the concrete example, and it exists precisely because the vendor concluded that training-data knowledge was not good enough. Then verify the outcome rather than the intent: a test that asserts an unauthenticated client cannot read a table is worth more than any amount of instruction, and it is the kind of test agents are perfectly capable of writing.

For leadership. Two dates matter. The first is October 30, 2026, when Supabase's new default reaches existing projects — useful, and not a remediation of anything you already deployed. The second is whenever your organisation last shipped an agent-built application to production without a security review, because that is the date your exposure starts. The governance question this report poses is not about AI risk in the abstract. It is whether anyone in your organisation can name every database your frontends talk to.

The broader pattern. UpGuard puts this in the lineage of Amazon S3 and public GitHub repositories — convenience-first defaults that produced systemic exposure until the platform changed the default rather than the documentation. That history suggests the fix works, and also that it takes years and leaves a large exposed installed base behind it. Supabase has started down that road. The 16,326 are the part the road does not reach.

Sources

Primary:

• UpGuard, Greg Pollock, "Everything Everywhere: Systemic Data Exposure in Supabase Apps", September 25, 2026.
• Supabase, Pedro Rodrigues, "AI Agents Know About Supabase. They Don't Always Use It Right.", April 9, 2026.
• Supabase changelog, "Breaking Change: Tables not exposed to Data and GraphQL API automatically", April 28, 2026.
• Supabase documentation, "Securing your API".
• Wiz, "Hacking Moltbook: The AI Social Network Any Human Can Control", February 2, 2026.

Coverage:

• TechCrunch, "Some Supabase customers are publicly exposing reams of people's data to the web", September 25, 2026 — carries Supabase CISO Bil Harmer's statement.
• BleepingComputer, "Misconfigured Supabase apps expose data in over 16,000 databases", September 25, 2026.
• Unite.AI, "UpGuard Study Finds 16,326 Supabase Databases Exposing Readable Tables", September 2026.