A report published on DEV Community describes a "$0 security breach" in which 24,664 AI-built apps allegedly leaked more than 80,000 user records, including passport numbers, through Supabase databases. This AI-built apps data leak Supabase case is a useful reminder that speed of development and safety of user data are not the same thing.
A note on sourcing: the source material available to us is limited to the report's headline and a short summary. It does not tell us who identified the exposure, how the apps were found, or which specific apps were affected. This article sticks to what the report states and clearly labels any general background as such.
How misconfigured databases exposed user records
According to the report's title, the exposed records came from apps built with AI tools that used Supabase as their backend. The headline also frames the incident as costing nothing to carry out, which suggests no sophisticated hacking was involved. The source does not detail the mechanics.
As general background (not drawn from the report): Supabase is a hosted database service, and access to its data is typically controlled by rules set by whoever builds the app, such as row level security. If those rules are missing or too permissive, data can be readable by people who should not see it. That is a configuration problem rather than a flaw that requires breaking in.
Why vibe coding creates this security gap
"Vibe coding" refers to building software by describing what you want to an AI tool and accepting the generated code with little manual review. It can turn an idea into a working app in hours. The trade-off is that security settings are easy to overlook when the app appears to work.
An app can look and behave perfectly while its backend is open to anyone who knows where to look. Nothing on the screen tells a user, or often the builder, that something is wrong. This is why a polished interface is a poor indicator of how carefully data is protected.
This also fits a wider pattern of AI tools changing the risk picture. Our coverage of how the Aurora ransomware gang deploys an AI coding agent in attacks and how Qilin uses AI tools as Japan ransomware attacks rise shows AI speeding up work on the attacker side too.
What data was exposed and who is at risk
The report says the exposed records number more than 80,000 and include passport numbers. Passport details are among the most sensitive identifiers a person can share, because they are hard to replace and can support identity fraud when combined with a name, email address, or date of birth.
The source does not specify which other fields were exposed or which countries the affected users are in. Anyone who signed up for a newer app and uploaded identity documents or personal details is potentially in the group worth paying attention to, especially if the app came from a small or unknown developer.
What This Means For You
You usually cannot see how an app protects its database, so the practical defense is to control what you hand over.
- Question the need. If an app asks for a passport number or ID scan, ask whether the service genuinely requires it.
- Check the developer. Look for a named company, a privacy policy, and a way to contact support. Be cautious with brand-new apps that have none of these.
- Use unique credentials. A separate password and an email alias for each new service limit the damage if one record set is exposed.
- Skip optional fields. Leave out phone numbers, addresses, and document uploads unless they are required.
- Watch for follow-on scams. Exposed records are often reused for phishing and fraud, as seen when Paidwork user records were added to HIBP.
How to vet apps and limit what you share
Before creating an account with a new app, take a minute to review it. Prefer services that explain how they store data and that have an established track record. If an app wants identity documents, consider whether a more established alternative exists.
If you build apps yourself, the general advice is to review database access rules before launch rather than trusting generated code, and to test your app as an unauthenticated visitor to see what data is reachable.
Takeaways
The reported AI-built apps data leak Supabase incident shows that a working app is not necessarily a secure one. Start by checking whether your email appears in known breaches using a service such as Have I Been Pwned, and change passwords for any account that does. Then give every new app only the minimum personal data it needs. To see how exposed records are put to use, read our coverage of the Paidwork breach that leaked 23M emails and banking data.




