Key Takeaways

  • UpGuard identified 16,326 Supabase databases with publicly readable tables across roughly 300,000 domains.
  • The findings indicate widespread exposure risk rather than confirmed breaches or a verified count of affected individuals.
  • Missing row-level security and confusion over publishable client keys appear to be central configuration problems.

UpGuard has identified 16,326 Supabase databases with publicly readable tables, highlighting how configuration errors can undermine the security controls surrounding rapidly developed web applications.

The September 2026 research began with roughly 300,000 domains showing signs of Supabase use. Researchers tested whether tables could be queried without appropriate authorization, initially looking for a "users" table before examining other accessible table names and schemas.

More than half of the exposed databases contained schema indicators associated with personally identifiable information. Smaller subsets included fields for passwords and authentication tokens, while a very small number appeared to contain plausible payment-card information.

These findings represent exposure risk rather than proof of criminal access, and the 16,326 figure is an exposed database count rather than a tally of affected users. Much of the broad analysis relied on table schemas to infer the kinds of information present. Deeper reviews of selected applications, however, confirmed that readable records were available.

Specific exposures illustrate the severity of these configuration oversights. A U.S. valet service exposed more than 100,000 customer records containing contact information, license plates, and visit histories. A Canadian immigration service exposed nearly 5,000 user records, including 884 plaintext passwords.

The research team also reported exposed identity and payment-account information, along with more than 100,000 private messages, at an India-based adult creator platform. A Philippines-based OTP service exposed information concerning more than 2,000 users and 100,000 SMS messages, while an African government consulate exposed records relating to 25,000 people, including addresses and emergency housing locations.

Because Supabase client applications are designed to communicate directly with backend services, a publishable key often appears in browser code without functioning as a traditional secret. Database security instead depends heavily on authorization controls—particularly row-level security—to restrict what each user or role can read or modify.

When developers mistake a publishable key for the primary protective barrier and fail to implement row-level security, the database may respond to requests that the application interface never intended ordinary users to make. Attackers can bypass the need for sophisticated exploits if the underlying API inherently grants excessive access.

Supabase stated that projects are secure by default, emphasizing that customer configuration remains material to data protection, according to BleepingComputer. The platform encourages users to review its security advisories and API security guidance, verify policies on every exposed table, and test access using unauthenticated and low-privilege accounts.

More than 60% of newly created Supabase databases reportedly involve AI-assisted development, reflecting the platform's popularity among developers using coding agents to prototype applications. UpGuard associated many of the observed configuration mistakes with AI-generated projects, though the analysis did not establish that every affected site was created by an AI coding agent.

The core issue extends beyond AI tooling to the gap between generating functional software and validating its authorization model. Fast prototyping can produce an interface, database, and authentication flow in hours, frequently leaving ownership boundaries and data-access policies poorly defined.

The Lovable-related issue disclosed in 2025 and tracked as CVE-2025-48757 offered an earlier warning about security risks surrounding AI-built applications and Supabase configurations. However, human-written applications can expose data through the exact same architectural oversights.

Enterprise mitigation strategies align closely with the NIST SP 800-207 Zero Trust Architecture, which mandates least-privilege access and continuous authorization over implicit trust in client keys. Implementing robust Supabase row-level security policies enforces this zero-trust principle directly at the data layer.

Security teams should inventory public tables, verify that row-level security is enabled and effective, remove plaintext passwords, rotate exposed authentication material, and monitor anonymous queries for unusual enumeration. Organizations can also incorporate automated authorization testing into deployment pipelines and evaluate applications against the OWASP Application Security Verification Standard.

While AI coding tools significantly shorten development cycles, they inherently compress the time available for architectural security review. Organizations adopting Supabase and similar backend-as-a-service platforms must implement deployment gates that treat strict data authorization as a mandatory release criterion rather than a post-launch cleanup task.