Supabase Data Exposure: How 16,326 Databases Became Readable

The Supabase data exposure documented by UpGuard left 16,326 databases with readable tables. However, the finding was not a breach of Supabase itself. It involved insecure database configurations that could make data accessible through the Supabase Data API.

Researchers identified Supabase database addresses and public API keys from web-accessible sources. They then tested whether common tables could be queried. Access depended on PostgreSQL grants and, where enabled and applicable, Row Level Security (RLS) policies.

UpGuard has not publicly confirmed malicious third-party access to the exposed databases.

What Caused the Supabase Data Exposure?

UpGuard used BuiltWith technographic data and the Chrome UX Report dataset to identify around 300,000 domains with indicators of Supabase usage.

Supabase key names and database addresses can appear in public JavaScript files. These details gave researchers the information needed to query the Data API. Whether data was accessible then depended on the project’s database configuration.

UpGuard documented several significant cases:

• US valet service CRM: Records for more than 100,000 customers were exposed. Every record contained a phone number, while about 78,000 also contained license plate numbers. Of the exposed email addresses, 4,560 belonged to third-party corporate domains, including universities and Fortune 500 companies.
• Canadian immigration service: Nearly 5,000 user records were exposed, including 884 with a plaintext password.
• Philippines OTP service: More than 2,000 users and over 100,000 SMS messages were exposed. The messages included OTP codes, sender IDs and SIM codes.

UpGuard also documented significant exposure involving an African government consulate and an India-based adult creator platform.

The researchers primarily inferred data types from table schemas. They manually investigated a smaller number of cases where metadata suggested significant exposure.

How Could a users Query Expose Supabase Data?

The exposure involved three separate layers: public client keys, database grants and RLS configuration.

Public Client Keys Are Not Secrets

Supabase’s legacy anon key is designed for use in public client code. Supabase now recommends publishable keys for public clients instead.

With a publishable or legacy anon key, unauthenticated requests use the anon PostgreSQL role. Signed-in users use authenticated. PostgreSQL evaluates table grants before RLS.

Supabase’s secret keys and legacy service_role keys provide elevated access through the service_role PostgreSQL role. Administrative requests operating as service_role without a user access token bypass RLS.

Therefore, exposing a public client key is not by itself the security failure. The surrounding database permissions determine what that key can reach.

Legacy Grants Can Make Tables Reachable

Projects using Supabase’s legacy grant defaults can automatically make new tables reachable through the Data API.

On those projects, tables created in public receive SELECT, INSERT, UPDATE and DELETE privileges for anon, authenticated and service_role.

RLS then restricts rows for roles subject to RLS. If RLS is missing or improperly configured, a public client can potentially read rows permitted to the anon role.

RLS Depends on How Tables Are Created

Supabase’s Table Editor enables RLS by default. Tables created through the SQL Editor or other tooling require RLS to be enabled explicitly.

UpGuard notes that programmatically created tables can therefore lack RLS unless the provisioning workflow enables it.

One exposure path combines those conditions: automatic anon grants make a table reachable, while missing or inadequate RLS allows unintended row access.

How Scanning the users Table Scaled the Investigation

UpGuard queried for the common users table name and observed three possible outcomes:

• no accessible data;
• a hint identifying another accessible table; or
• a page of results.

When users did not exist but other data was accessible, UpGuard reports that the response could provide another accessible table name as a hint.

Separately, Supabase documents 42501 permission errors that can suggest the GRANT statement required for an attempted table operation.

What Has Supabase Changed to Reduce Data Exposure?

On May 29, 2025, developer Matt Palmer published details of CVE-2025-48757. The authorization issue affected certain Lovable-generated applications using Supabase without sufficiently restrictive RLS policies.

Supabase enables RLS by default for tables created through the Table Editor. SQL- and tool-created tables still require explicit RLS configuration.

Supabase has also started moving toward explicit Data API grants. The new setting began becoming the default for new projects on May 30, 2026. Supabase plans to apply it to all existing projects on October 30, 2026.

Once enabled, newly created tables in public require an explicit grant before the Data API can access them. Existing tables retain their current grants.

AI development provides additional context, but not a proven cause. Supabase reported in June 2026 that more than 60% of new databases were being launched by some form of AI tool.

UpGuard argues that AI coding agents may help explain the exposure pattern. However, its methodology did not establish that every affected site was built using an AI coding agent.

What Is Confirmed About the Supabase Exposure?

How Should Teams Fix the Supabase Data Exposure?

Endpoint, OS or browser patches do not correct these database-access misconfigurations. Remediation belongs in Supabase database and Data API access controls.

1. Audit RLS and Exposed Objects

Review every table exposed through the Data API. Confirm that RLS is enabled where required and that policies restrict rows and operations as intended.

Review views separately. On PostgreSQL 15+, security_invoker = true makes a view obey the underlying tables’ RLS policies for the querying user. Otherwise, restrict client-role access or keep sensitive views in an unexposed schema.

2. Tighten Grants and Functions

Remove unnecessary privileges from Data API roles and grant access explicitly.

Review SELECT, INSERT, UPDATE and DELETE permissions on tables. Also review EXECUTE on functions and USAGE or SELECT on sequences.

Restrict function execution from PUBLIC and unnecessary roles.

Pay particular attention to SECURITY DEFINER functions because they execute with the function owner’s privileges. Keep them out of schemas exposed through the Data API and explicitly configure search_path.

3. Reduce Data API Exposure

Disable the Data API when an application does not use Supabase client libraries or REST/GraphQL data endpoints.

Supabase states that its auto-generated REST endpoints do not respond when the Data API is disabled, regardless of grants or RLS configuration.

Teams should also run Supabase’s Security Advisor and review its findings alongside the platform’s API security guidance.

4. Investigate Exposed Credentials

Determine whether readable tables contained passwords, tokens or other credentials.

Rotate exposed tokens and reset passwords when investigation confirms or reasonably indicates credential exposure.

For corporate accounts, MFA can reduce reliance on passwords alone. Phishing-resistant authentication provides stronger protection where appropriate.

Database configuration changes address the root cause of this exposure. Endpoint and identity governance provide an additional defense-in-depth layer by helping organizations govern development tools and reduce the risk associated with exposed or reused credentials.

Featured resource

Strengthen Data Security Across Managed Endpoints

Explore practical approaches to protecting business data and strengthening endpoint-level data security with Hexnode UEM.

Download the whitepaper

How Can Hexnode Support Teams Using Supabase?

The exposed component is a cloud database configuration. Hexnode does not replace Supabase RLS, PostgreSQL grants or Data API configuration. Its relevance sits at adjacent endpoint and identity layers.

Govern Developer Endpoints with Hexnode UEM

AI coding tools can generate database changes that still require security review. When these tools run on corporate endpoints, IT teams can govern the environment around them.

Hexnode UEM provides application visibility and supported application controls on managed endpoints. Organizations can use these capabilities to identify known development tools and restrict unsanctioned applications where supported.

Hexnode UEM also supports custom scripts on managed Windows, macOS and Linux devices, with RBAC over which technicians may run them and an auditable Action History.

These controls do not fix Supabase configuration. They help govern the endpoints and development workflows surrounding it.

Protect Corporate Identities with Hexnode IdP

UpGuard found 4,560 valet-customer email addresses belonging to third-party corporate domains. Separately, the Canadian immigration service exposed 884 plaintext passwords.

UpGuard did not establish that those passwords were reused corporate credentials. However, password reuse could turn third-party credential exposure into an enterprise account risk.

Hexnode IdP provides SSO and MFA, contextual authentication, and conditional access based on user identity, device compliance and security context. These controls can add verification or enforce access requirements according to the context of an access request.

These controls provide an additional identity layer when credentials alone should not determine access.

What Should Teams Take Away?

The Supabase data exposure documented by UpGuard did not require exploitation of a Supabase software vulnerability. Researchers identified 16,326 databases with readable tables using information available through web-accessible sources.

Supabase’s move toward explicit grants reduces accidental Data API exposure for newly created public tables. However, existing tables retain their current grants.

Teams should therefore review existing projects for appropriate grants, RLS policies and exposed database objects rather than assuming newer defaults have corrected previously deployed configurations.