Full Report
Researchers found more than 16,000 misconfigured Supabase databases exposing readable tables with personally identifiable information, passwords, or authentication tokens. [...]
Analysis Summary
# Incident Report: Systemic Data Exposure via Misconfigured Supabase Instances
## Executive Summary
A large-scale security research project identified over 16,000 Supabase databases misconfigured to expose sensitive tables to the public internet. The exposure resulted from a failure to implement Row-Level Security (RLS) policies, leading to the leak of PII, plaintext passwords, and authentication tokens across various global sectors. The incident highlights a systemic risk in AI-assisted development where human oversight of security configurations is lacking.
## Incident Details
- **Discovery Date:** September 2026 (Reported)
- **Incident Date:** Ongoing (Discovered during research)
- **Affected Organization:** 16,000+ organizations globally using Supabase
- **Sector:** Technology, Government, Healthcare, Adult Entertainment, Immigration, and Logistics
- **Geography:** Global (Specific mentions of USA, Canada, India, Philippines, and Africa)
## Timeline of Events
### Initial Access
- **Date/Time:** Continuous exposure prior to discovery.
- **Vector:** Misconfigured Row-Level Security (RLS) and public API key exposure.
- **Details:** Developers failed to enable or correctly configure RLS on PostgreSQL tables, allowing anyone with the project’s public API key to query sensitive data via standard Supabase client libraries.
### Lateral Movement
- **Details:** Not applicable in a traditional sense; however, the exposure of **authentication tokens** and **passwords** allows for potential account takeover (ATO) and lateral movement into user accounts or connected third-party services.
### Data Exfiltration/Impact
- **Details:** Massive quantities of PII were exposed. Notable leaks include:
- 100,000+ customer records (valet service) including license plates.
- 884 plaintext passwords (immigration service).
- 100,000+ private messages and payment info (adult creator platform).
- 100,000+ SMS messages including OTPs (OTP service).
- 25,000 government records including emergency housing locations.
### Detection & Response
- **Detection:** Identified by UpGuard researchers during a proactive scan of ~300,000 domains associated with Supabase.
- **Response:** UpGuard notified affected application owners where significant exposure was identified. Supabase pointed users toward existing security advisors and documentation.
## Attack Methodology
- **Initial Access:** Exploitation of default public access on tables where RLS was disabled.
- **Persistence:** Not required; data is persistently available via public API endpoints.
- **Privilege Escalation:** Use of exposed authentication tokens or plaintext passwords to gain administrative or user-level access.
- **Defense Evasion:** None; the queries appear as legitimate API traffic.
- **Credential Access:** Extraction of plaintext passwords and auth tokens from exposed `users` or similar tables.
- **Discovery:** Automated scanning of domains to identify Supabase backend schemas.
- **Lateral Movement:** Account Takeover (ATO) using leaked credentials.
- **Collection:** Direct querying of PostgreSQL tables via Supabase API.
- **Exfiltration:** Standard HTTP/REST requests.
- **Impact:** Massive data breach, privacy violations, and potential identity theft.
## Impact Assessment
- **Financial:** High potential for regulatory fines (GDPR, CCPA) for affected entities.
- **Data Breach:** Over 16,000 databases; millions of rows of PII, credentials, and private communications.
- **Operational:** Potential for service disruption if attackers used leaked tokens to modify or delete data.
- **Reputational:** Significant damage to the affected organizations and a highlighted risk for AI-assisted coding platforms.
## Indicators of Compromise
- **Network Indicators:** Requests to `[project-id].supabase.co/rest/v1/[table-name]` from unknown or suspicious IP addresses.
- **File Indicators:** N/A (Cloud database configuration).
- **Behavioral Indicators:** Large-scale data pulls from tables like `users`, `profiles`, or `messages` without valid user-specific session headers.
## Response Actions
- **Containment:** Notifications sent to affected site owners to enable RLS.
- **Eradication:** Implementation of proper Row-Level Security policies on all tables.
- **Recovery:** Rotating all exposed passwords and authentication tokens; revoking leaked API keys if necessary.
## Lessons Learned
- **AI-Assisted Risks:** AI coding agents often prioritize functional code over secure configuration; humans must manually audit security settings.
- **Defaults Matter:** If a security feature (like RLS) is not "on by default," developers—especially novices—are likely to overlook it.
- **Public API Key Misunderstanding:** Developers often mistake public API keys for secure authentication, failing to realize these keys require RLS to protect data.
## Recommendations
- **Enable Row-Level Security (RLS):** Ensure RLS is enabled for every table in the Supabase dashboard.
- **Audit Table Permissions:** Use the Supabase "Security Advisor" tool to identify tables without RLS.
- **Credential Hygiene:** Never store plaintext passwords; use Supabase Auth for managed, secure authentication.
- **DevSecOps Integration:** Implement automated schema scanning to detect public-facing tables before deploying to production.