Over 16,000 open doors, one common cause
UpGuard, the cybersecurity research firm, disclosed on September 26, 2026 that it had identified 16,326 Supabase-backed databases with publicly readable tables, meaning anyone with the right URL could read data never intended to leave the application. Supabase is a popular backend-as-a-service platform built on Postgres, widely used because it lets developers stand up a production-grade database and authentication layer in minutes rather than weeks. That speed is exactly what turned into the liability here.
The exposed data runs across categories that matter: personally identifiable information in over half of the affected databases, plaintext passwords, authentication tokens, one-time password codes, passport and driver's license details, private messages, and in rare cases credit card data. The scale of individual incidents is striking. An India-based OnlyFans-style platform exposed over 65,000 people's records. A Philippines OTP service leaked more than 100,000 SMS messages containing one-time codes. A US valet service exposed over 100,000 customer records. A government consulate database exposed location and personal data for 25,000 citizens. A Canadian immigration service left roughly 5,000 records open, including 884 accounts with passwords stored in plaintext.
AI coding tools as the exposure vector
The specific mechanism UpGuard points to is a near-universal developer configuration failure rather than a Supabase platform vulnerability: apps built without row-level security policies enabled, combined with public API keys being mishandled as if they were secret keys. The research ties a meaningful share of these failures directly to vibe-coding platforms, tools that generate full applications from natural language prompts, with Lovable named specifically as a primary vector. Ryan McCurdy of Liquibase summarized the dynamic bluntly: 'AI has dramatically lowered the barrier to building software. The same tools that make development easier also make it easier to push a bad configuration into production.'
Jacob Krell of Suzu Labs drew the sharper distinction for engineering leaders: 'A working application and a secure application are different achievements. An AI agent can produce a functional schema in seconds, but it cannot decide whether the query is authorized.' That is the core failure mode. Row-level security in Postgres is not enabled by default in every template, and an AI coding agent optimizing for a working demo has no inherent incentive to enable it unless the prompt, the template or the platform forces the decision.
Supabase's defense is correct and also not enough
Supabase's chief information officer, Bil Harmer, responded that the platform provides 'secure defaults and tooling, and customers control how their own projects are configured,' and the company says it notifies affected customers when issues are found. That is a factually defensible position: Supabase did not fail to ship a security feature, customers failed to enable one that exists. It is also an answer that will satisfy almost no enterprise buyer, because the practical reality at scale is that a shared-responsibility model only works if the party responsible actually understands what they are responsible for, and a growing share of Supabase's newest users are AI agents and the developers prompting them, not security-trained engineers.
UpGuard's framing of the broader trend is the number that should concern every engineering leader more than any single exposed database: over 60 percent of new databases are now being created using AI coding agents. That share is approaching the default way new applications get built, which means the row-level-security gap identified here is a preview of the baseline exposure rate for AI-generated backends industry-wide, rather than an isolated incident confined to one platform or one vibe-coding tool.
The scale makes this a systemic risk, not an edge case
Treat the 16,326 figure as a floor, not a ceiling. UpGuard's scan covers what was discoverable through publicly readable Supabase tables at a single point in time, and Supabase is one backend-as-a-service provider among several, including Firebase, PlanetScale and various Postgres-as-a-service offerings, that have made similar speed tradeoffs available to AI coding agents. The underlying dynamic, an agent optimizing for a working demo with no built-in incentive to enable access controls, applies equally across that entire category of tooling.
For an enterprise buyer, the relevant question shifts from 'did we use Supabase' to 'does any team here use an AI coding tool to touch a production database of any kind.' Shadow IT has always existed, but AI coding agents compress the time from idea to deployed database from weeks to minutes, which means a well-meaning product team can stand up and populate a customer-facing database with real personal data before security has any visibility into the project at all.
The control you need before your next AI-built feature ships
If any team in your organization is using AI coding tools, Lovable, Cursor, Claude Code, Replit or similar, to stand up application backends, assume this incident describes a gap that already exists in your own environment until proven otherwise. Krell's recommended checklist is concrete and worth adopting directly: test live APIs as both an anonymous and an authenticated user, inspect row-level security policies and database permissions explicitly rather than trusting the template, and verify no secret keys have leaked into client-side code.
McCurdy's broader recommendation is the architectural fix: make security the default path through automated policy checks on every database change before it reaches production, regardless of whether a human engineer or an AI agent generated the change. The speed advantage of AI-assisted development is real and worth capturing. Put an automated gate between generated code and production data before your next AI-built feature touches a customer record, because that gate is what stands between your organization and UpGuard's next list.
