What happened to the 16,000 exposed Supabase databases
On 25 September 2026, UpGuard published the largest study so far of Supabase data exposure. It found 16,326 Supabase databases with tables that anyone on the internet could read. Over half showed signs of personal data. A smaller share held passwords or authentication tokens, and a very small number held what looked like credit card data. TechCrunch covered the research the same day and called it reams of people's data left open to the web.
Supabase was not hacked. Every one of these databases was open because of how the app on top of it was built. Most of those apps were built fast, often with AI coding tools, by people who shipped a working product without checking who else could read its data. That is the vibe-coded app problem in one number.
If you run a small business and you are thinking about adding AI to your product or your operations, this story is about you too. Here is what went wrong, how multi-tenant SaaS apps should keep customers apart, and how to add AI to your business, including AI tools for Bangladeshi small businesses, without becoming the next example in a report like this.
What the leaked data looked like
UpGuard did not name the apps, but it described several. An Indian adult content site exposed 65,467 user records with passport, driving licence and PAN card numbers, plus over 100,000 private messages. A US valet service leaked more than 100,000 customer records, including about 78,000 licence plates. A Canadian immigration service exposed nearly 5,000 records, and 884 of them stored the password in plain text. An African government consulate exposed 25,000 people, including which emergency housing location each person was staying in.
Ecommerce and restaurant sites were the most likely to leak personal data and to have payments wired in. UpGuard also found that the problem is global, with developing regions tending to leak more. That includes South Asia, where a huge amount of small business software is now being built on exactly this stack.
Why vibe-coded apps leak data
Supabase gives every project a public key that ships inside the website's JavaScript. That is by design. The key is safe only when the database checks every request against rules called Row Level Security, or RLS. With RLS on and written well, the public key can only reach the rows the signed-in user is allowed to see. With RLS off, the public key reads the whole table.
UpGuard and earlier researchers found three recurring mistakes.
- RLS was never switched on. Supabase turns RLS on by default for tables created in its dashboard. Tables created with SQL, migrations or through the API do not get it automatically, and that is exactly how AI coding agents create tables.
- RLS was on, but the rules let everyone in. A policy that exists is not the same as a policy that restricts anything. A rule that effectively says allow all passes a quick check and protects nothing.
- Keys were treated the wrong way round. Some apps treated the public key as if it were secret, and trusted it to guard data. Worse, some shipped a privileged key to the browser, which skips RLS entirely.
None of this is new. In March 2025 a developer reported that many apps built on the Lovable platform had the same flaw, tracked as CVE-2025-48757. Wiz found in February 2026 that Moltbook, a social network for AI agents, was leaking 35,000 email addresses and 1.5 million API tokens from its Supabase backend. UpGuard's study shows the pattern has spread from one platform to the whole ecosystem, including apps built with Claude Code and Codex.
What Supabase says
Supabase's chief information security officer, Bil Harmer, told TechCrunch that projects are secure by default and that security is shared. In his words, Supabase provides secure defaults and tooling, and customers control how their own projects are configured. That is fair, and it is also the point. The platform will not stop you from shipping a table with no rules. Somebody on your side has to.
An AI coding tool writes the code you ask for. It does not know which of your customers is allowed to see which row unless someone decides that and enforces it in the database.
I wrote about this risk earlier in why vibe coding is a timebomb. This study is the timebomb going off at scale.
Multi-tenant SaaS, where one bad rule leaks every customer
A multi-tenant SaaS is one app serving many businesses from one database. A CRM, a booking tool, a school management system or a POS sold to hundreds of shops is almost always multi-tenant. The whole product rests on one promise: shop A never sees shop B's customers.
In a single-user app, a missing rule leaks one person's data. In a multi-tenant SaaS, a missing rule on one table leaks every tenant at once. That is why tenant isolation belongs in the database, not only in the application code. If the app has a bug, a forgotten filter or an AI feature that builds its own queries, the database still refuses to return another tenant's rows.
What tenant isolation looks like in practice
Every table that holds tenant data gets a tenant_id column, RLS switched on, and a policy that ties rows to the tenants the signed-in user belongs to. A minimal version in Postgres looks like this.
alter table orders enable row level security;
create policy "members read own tenant orders"
on orders for select
to authenticated
using (
tenant_id in (
select tenant_id from memberships
where user_id = (select auth.uid())
)
);Then you repeat that thinking for insert, update and delete, for storage buckets, and for any database function that runs with elevated rights. On the Tryneth backend, a multi-tenant AI marketing and CRM platform, I put Row Level Security on 97 of 98 production tables for exactly this reason. The AI agents in that system physically cannot read data the signed-in customer cannot.
A 15-minute check for your own Supabase app
| Check | How to do it | Red flag |
|---|---|---|
| RLS on every public table | Open the Security Advisor in the Supabase dashboard | Any RLS disabled in public warning |
| Policies that restrict | Read each policy on tables with customer data | A policy that returns true for everyone |
| Keys in the browser | Search your built JavaScript for key strings | A secret or service role key in frontend code |
| Anonymous read test | Query a table with only the public key, not signed in | Any rows come back that should be private |
| Storage buckets | List buckets and their public setting | ID cards, invoices or uploads in a public bucket |
| Tenant isolation | Sign in as tenant A, request tenant B's IDs | Anything other than an empty result |
The Supabase Security Advisor flags the three most common problems automatically, under the names rls_disabled_in_public, rls_enabled_no_policy and permissive_rls_policy. If any of them show up on a live app, fix that before you do anything else in this article.
How to add AI to your business without leaking customer data
AI features make this problem worse, not better. A chatbot that reads your order history, an assistant that drafts replies from your CRM or an agent that writes its own database queries all need access to real customer data. If the database rules are weak, the AI will happily read and repeat whatever it can reach. A prompt that says only show this customer their own orders is a suggestion. RLS is a wall.
Here is the order I follow when I help a small business add AI.
- Pick one job with a number attached. Replies to customer messages, invoice data entry, product descriptions. One task, one metric such as hours saved per week.
- Map the data it touches. List which tables and files the AI needs, and which it must never see. Payment details, national ID numbers and passwords stay out.
- Lock down access before you connect the AI. RLS on every table, tenant isolation tested, secret keys only on the server.
- Run the AI on your server, not in the browser. Model API keys never ship to the frontend. The server checks who is asking, then calls the model with only the data that person may see.
- Test with real questions. Collect 50 real customer questions, check the answers, and try a few that should be refused.
- Launch small and watch the logs. Roll out to a slice of users, log every AI call, and keep a spending cap on the model account.
Most AI projects fail somewhere in steps three to six, which I cover in detail in why AI pilots stall before production. The model is rarely the problem. Data, permissions and cost usually are.
AI tools for Bangladeshi small businesses
Bangladesh is a good example of where this matters right now. Small businesses here sell through Facebook pages, take orders on WhatsApp and Messenger, and get paid through bKash and Nagad. A July 2026 business survey by Emerging Credit Rating found that none of the SMEs it surveyed had adopted AI yet. The top barriers were implementation cost at 25 percent, lack of skilled people at 23 percent and unclear return at 17 percent. Data privacy and security came next at 12 percent.
That last worry is justified. Bangladesh gazetted the Personal Data Protection Ordinance on 6 November 2025. It applies to anyone processing Bangladeshi citizens' personal data, allows fines of up to 5 percent of annual turnover, and gives businesses an 18 month window before key sections take effect. A leaky app built this year is a compliance problem by 2027.
The good news is that a Bangladeshi small business does not need custom software to start with AI. Off-the-shelf tools cover most first steps.
| Business need | Tool type | Examples | Data to keep out |
|---|---|---|---|
| Replying to Messenger and WhatsApp orders | Chat automation | BotSailor, WhatsApp Business auto replies | Full payment and ID details |
| Bookkeeping and sales records | AI accounting in Bangla | Hishabee | Customer passwords, card numbers |
| Captions, product descriptions, ads | General AI assistants | ChatGPT, Gemini, Claude | Customer names and phone numbers |
| Product photos and social posts | AI design tools | Canva with AI features | Nothing sensitive needed |
| Your own booking, CRM or POS app | Custom build | Supabase or Postgres with RLS, AI on the server | Everything, enforced in the database |
How to choose a safe AI tool
Before you connect any tool to your customer data, ask four questions. Where is the data stored? Can I delete it? Who at the vendor can read it? Can I export everything if I leave? If the vendor cannot answer clearly, do not upload your customer list. And if you are paying someone to build a custom app for your shop, ask them to show you the RLS policies and the anonymous read test from the table above. A developer who cannot show you those has not done them.
Questions people ask about the Supabase exposure
Was Supabase hacked?
No. UpGuard found 16,326 databases exposed through how individual apps were configured, not through a flaw in Supabase itself. The usual cause was Row Level Security switched off or written too loosely, so the public key that ships in every Supabase website could read whole tables.
How do I know if my Supabase database is exposed?
Open the Security Advisor in your Supabase dashboard and fix any warning about RLS being disabled or permissive. Then query your tables using only the public key while signed out. If private rows come back, your data is exposed. Also check that no secret or service role key appears in your frontend code.
Are vibe-coded apps safe to use for a real business?
They can be, once an engineer reviews them. AI coding tools produce working features quickly, but they often create tables without access rules and put keys in the wrong place. Treat a vibe-coded app as a prototype until someone has checked its database rules, keys and storage settings.
How does a multi-tenant SaaS keep customer data separate?
Each row carries a tenant ID, and Row Level Security policies in the database only return rows for tenants the signed-in user belongs to. Doing this in the database, rather than only in app code, means isolation still holds if the application or an AI feature has a bug.
What are the best AI tools for small businesses in Bangladesh?
Start with the jobs that take the most time. Chat automation such as BotSailor handles Messenger and WhatsApp orders, Hishabee covers bookkeeping in Bangla, and ChatGPT, Gemini or Claude write captions and product descriptions. Keep payment details and national ID numbers out of every tool unless you know where that data is stored.
How do I add AI to my business safely?
Pick one task with a measurable goal, list the data the AI needs and the data it must never see, and lock down database access before connecting any model. Keep model keys on your server, test with real questions, and roll out to a small group first with logging and a spending cap.
Want a second pair of eyes on your app?
If your product runs on Supabase, was built quickly, or is about to get an AI feature, an hour of review now is cheaper than a breach later. I will check your RLS policies, keys, storage and tenant isolation, and tell you plainly what to fix first. See how hiring me works, or send me a message.
I build secure backends and APIs, design multi-tenant systems, and ship AI features for small teams from Dhaka. If you want to know what that role looks like, read what a forward deployed engineer does. I answer every message myself.