16,000+ Exposed Supabase Databases: The Security Risk of Cloud Misconfiguration

Executive Summary: Security researchers recently identified more than 16,000 Supabase databases exposing readable tables, with more than half showing indicators of personally identifiable information (PII). The findings did not establish a breach of the Supabase platform or the discovery of a new zero-day vulnerability. Instead, they highlighted how configuration weaknesses across individual applications can expose sensitive data.  As AI-assisted development accelerates how quickly applications move from idea to production, the findings highlight a growing security challenge: infrastructure can be deployed faster than organizations can verify whether it is securely configured.

16,000+ Exposed Databases. No Zero-Day Required.

In September 2026, UpGuard researchers published findings from an analysis of applications built on Supabase, the popular open-source backend platform based on PostgreSQL.

Researchers analyzed 16,326 databases with publicly readable tables. More than half had schema indicators suggesting the presence of personally identifiable information (PII). Some databases also had schema indicators associated with passwords and authentication tokens, while a smaller number showed potential exposure of payment-related data. 

The researchers investigated a subset of the databases to confirm that meaningful data exposure existed and notified affected application owners.

The research did not establish a breach of Supabase’s underlying platform. Instead, it identified databases exposed through application-level configuration weaknesses. The findings highlight how platform defaults, development practices, and access-control decisions can combine to create security risks. 

What Caused the Supabase Database Exposures?

Supabase gives developers a fast way to build application backends, including databases, authentication, APIs and storage.

But making infrastructure easier to deploy doesn’t eliminate the need to configure access correctly.

Supabase applications can expose database functionality through APIs. The public anon key is designed to be included in frontend code, so it should not be treated as a secret. Security depends on controlling which database objects are exposed, granting only the necessary privileges, and correctly configuring Row Level Security (RLS). When these controls are missing or overly permissive, anyone with access to the relevant API and key may be able to retrieve data they should not see. 

When those controls are missing, overly permissive or incorrectly configured, data that was intended to remain restricted may become accessible.

That’s how a seemingly small configuration decision can have a significant security impact.

An application can work exactly as its developer intended. The database can be online. Authentication can work. The frontend can look perfectly normal.

And sensitive backend data can still be more accessible than anyone realizes.

How Row Level Security Protects Supabase Databases

Row Level Security is one of the most important controls for protecting data in Supabase.

RLS allows organizations to define policies determining which database rows a user or role is permitted to read, modify, or delete. Supabase recommends enabling RLS on tables in exposed schemas and appropriately restricting database privileges.

For example, an authenticated user of an application might need access to their own profile information.

They shouldn’t automatically have access to everyone else’s.

An appropriately configured RLS policy can enforce that distinction at the database level.

But the existence of a security control isn’t the same as having that control correctly configured.

A missing policy, excessive database privilege or unintended API exposure can create a path to sensitive information without generating an obvious operational failure.

That’s what makes configuration risk particularly difficult to detect.

“Working” Doesn’t Mean “Secure”

One of the most important lessons from the Supabase research is that a cloud misconfiguration doesn’t necessarily break anything.

In fact, the most dangerous configuration problems may be the ones that cause no obvious operational issue at all.

Nothing crashes.

No error appears.

No user submits a support ticket.

The application continues working.

Meanwhile, a database, API, storage resource or identity permission may be accessible far beyond its intended audience.

Traditional operational monitoring may never flag the problem because, from the application’s perspective, everything is functioning normally.

Security teams have to ask a different question: Is this resource configured the way it should be?

That question applies far beyond Supabase.

The same problem appears when a cloud storage bucket becomes public, a security group exposes an unnecessary port, an API allows excessive access, an identity receives privileges it doesn’t need or a development resource quietly becomes internet-facing.

The individual technologies change.

The underlying problem is the same: the configuration creates an unintended path to sensitive resources.

AI-Assisted Development Raises the Stakes

There’s another reason these findings deserve attention now.

AI is changing how quickly applications and infrastructure can be created.

AI coding assistants can generate application logic, connect databases, create APIs, configure services, and help developers move from an idea to a functioning application extraordinarily quickly.

That productivity is valuable.

But it creates a new security challenge.

Infrastructure can now be created and changed faster than ever. Security teams may have less time to answer fundamental questions:

• What was deployed?
• What is publicly reachable?
• Which identities have access?
• Are the correct security policies enabled?
• Are database permissions appropriately restricted?
• Has a development configuration quietly made its way into production?

AI doesn’t inherently create insecure infrastructure. But it can dramatically increase the volume and velocity of infrastructure being created.

If security visibility doesn’t operate at similar speed, the gap between deployment and validation grows.

The Platform Isn’t Necessarily the Problem

When thousands of applications using the same platform are found exposing information, it’s easy to conclude that the platform itself was breached.

That’s not what this research demonstrated.

Supabase provides controls designed to restrict database access, including PostgreSQL Row Level Security. It has also introduced additional safeguards around how new database tables are exposed through its Data API.

But cloud security operates under a shared responsibility model.

Platforms provide security capabilities.

Organizations still have to configure and maintain them correctly.

The same principle applies across AWS, Microsoft Azure, Google Cloud, SaaS applications, identity platforms, and modern development environments.

A powerful security control provides little protection if it isn’t enabled, appropriately scoped, or continuously monitored.

Why Cloud Misconfigurations Can Go Undetected

Configuration isn’t static.

Cloud environments change constantly.

Developers deploy resources. Applications gain integrations. Permissions change. APIs are created. Test environments become production environments. Infrastructure is automatically provisioned and modified.

Each change can alter an organization’s security posture.

A resource that was securely configured yesterday may not have the same posture today.

This is why point-in-time configuration reviews are increasingly insufficient.

An organization might validate an environment during deployment, perform a security assessment before launch, or review controls during an annual compliance audit.

But what happens after that?

Configuration drift can occur minutes, days, or months later.

And increasingly, automated systems and AI agents can accelerate the pace of those changes.

Security teams need visibility that changes with the environment.

How Organizations Can Prevent Database Misconfigurations

Preventing database exposure starts with enforcing strong access controls, but it can’t end there.

Organizations should apply least-privilege access, enable appropriate Row Level Security policies, restrict database and API permissions, identify publicly accessible resources, and continuously monitor for configuration drift.

They also need to understand context.

Not every configuration finding creates the same level of risk.

A publicly accessible development resource containing synthetic data is very different from an internet-facing production database containing customer information and authentication tokens.

Security teams need to understand not only what is misconfigured, but also what is exposed, who can reach it, and what business impact that exposure could create.

That context becomes increasingly important as environments grow larger and development accelerates.

Misconfiguration Is No Longer a Point-in-Time Problem

The Supabase findings demonstrate why cloud security posture can’t be treated as a deployment checklist.

Organizations need to continuously understand:

• Which resources are publicly accessible
• Where security controls are missing or disabled
• Whether permissions exceed what users or applications require
• Whether configurations have drifted from approved baselines
• Which exposures involve sensitive or business-critical resources
• Which misconfigurations should be remediated first

The goal isn’t to generate another list of configuration findings.

It’s to understand which configuration gaps create meaningful risk — and fix them before someone else discovers them.

From Misconfiguration to Continuous Security Posture

The 16,000+ exposed Supabase databases are a reminder of how modern security incidents can begin.

Not every exposure requires malware.

Not every attacker needs a zero-day.

Sometimes the path to sensitive data already exists.

As organizations adopt cloud services, SaaS platforms, and AI-assisted development at increasing speed, the gap between how quickly technology can be deployed and how quickly security teams can validate it becomes increasingly important.

Continuous security posture management helps close that gap by giving security teams visibility into changing environments, identifying risky configurations, and helping prioritize remediation before an overlooked setting becomes an incident.

Because the question shouldn’t simply be: “Did we configure it securely when we deployed it?”

It should be: “Is it configured securely right now?”

How CheckRed Helps Identify Cloud Misconfiguration Risk

CheckRed continuously evaluates security posture across cloud, SaaS, identity, DNS, certificates, DDoS protection, and compliance environments to identify configuration gaps, excessive permissions, exposure, and drift.

Instead of relying solely on point-in-time assessments, security teams can continuously identify changes in posture, understand risk in context, and prioritize remediation across complex environments.

As infrastructure becomes faster to deploy and easier to change, continuous visibility helps security teams keep pace.

See what configuration risks may be hiding in your environment.