Is your vibe-coded app open? The leaks behind Moltbook, Lovable apps and Tea
- API tokens exposed at Moltbook
- 1.5M
- Lovable apps leaking in a scan
- 1 in 10
- Tea images exposed
- 72,000
Most leaks in AI-built apps are not hacks. The database key ships inside the page, the tables have no access rules, or a storage bucket is public, so anyone who opens the site can read it. Here is what went wrong in three real cases and one prompt that checks your app for the same holes.
What it is
Moltbook (Wiz, February 2026). The founder said he didn't write a single line of code. The Supabase key sat in the page's JavaScript and row-level security was off, so anyone could read and write the whole database: 1.5 million API tokens, 35,000 emails and 4,060 private messages, some with OpenAI keys in plain text. Researchers found it within minutes, browsing like normal users, and could edit any post.
Lovable apps (CVE-2025-48757, Matt Palmer). A scan found 303 exposed endpoints across 170 of 1,645 apps, about 1 in 10. Missing row-level security left names, phone numbers, API keys and payment details readable by anyone. Lovable disputes the CVE.
Tea (July 2025). About 72,000 images, including 13,000 selfies and photo IDs from account checks, were exposed from a storage bucket that required no login.
The pattern is the same every time: nobody broke in, the door was simply open.
Steps
Step 1. Open Claude Code in your app's folder
Open the folder with your app's code. If your app lives in a builder, ask Claude how to get the code out of it, then open that folder.
Step 2. Paste the prompt
Claude checks your database rules, where your keys live, your storage buckets and your signup limits. It shows you what it found first, then fixes it.
Step 3. Watch the logged-out test
At the end Claude tries to read another user's data while logged out. If it gets nothing, the door is closed. If it gets data, it keeps fixing.
Copy this into Claude Code
Audit my app for data leaks and fix them: enable row-level security on every table with a policy per user, move every secret key to the server, make storage buckets private with signed URLs, add rate limits to signup and the API, and never store API keys in plain text. Show me what you found before you change anything. Then try to read another user's data while logged out and show me the result. If a setting has to be changed in a dashboard, tell me exactly where to click. If something doesn't work, explain what the problem is and fix it. I'm not a programmer: anything you can do yourself, do it yourself.
Want this working for your business?
- AI agents for your business
- Automations for the work you repeat
- 1:1 consulting calls
Good to know
Rotate leaked keys
If a secret key was ever in your page's code, moving it is not enough. Make a new key in the provider's dashboard so the old one stops working.
Row-level security, in plain words
It is a rule on every table: a user can only read and change their own rows. Without it, the public key in your page opens the whole table.
Private files
User photos and documents belong in a private bucket. The app hands out a short-lived signed link only when someone needs to see a file.
Rate limits
Moltbook counted 1.5 million agents but only 17,000 humans behind them: nothing stopped a script from signing up again and again. A limit on signup and the API stops that.
The honest read
- This closes the common holes from these three cases. It is not a full security audit: if your app handles payments or health data, get a professional review.
- Some settings live in your database dashboard, not in your code. Claude will tell you where to click, but you click.
- Lovable disputes the CVE. The numbers above come from the researcher's scan.
Want this built for your business?
I build AI agents and automations for businesses, and do 1:1 consulting calls. Message me on Instagram with what your business does, and I'll tell you what can be automated.
Message me on Instagram