Vibe coding security: why AI-built apps exposed data in 2026

The vibe coding security failures of 2026 share one root: access control that was missing or broken. In January, Wiz found Moltbook's Supabase database open to anyone who read the key in its front-end code. In April, Lovable confirmed that backend regressions had left chat history and source code of public projects reachable for about eleven weeks. On October 1, UpGuard reported 16,326 Supabase databases with tables anyone could read. None of these needed an advanced exploit. Access control was off, too loose, or enforced only in the interface. If an AI tool built your app, check the points below this week.

What changed

• Moltbook data exposure, January 31 to February 2: Wiz found a Supabase API key in Moltbook's client-side JavaScript and no working row-level security behind it. That gave unauthenticated read and write access to the production database, including 1.5 million API authentication tokens, 35,000 email addresses and private messages between agents. Wiz reported it on January 31, and the tables were secured in stages by February 1.
• Lovable security incident, February 3 to April 20: Lovable says backend regressions in February re-enabled public access to chat history and source code on public projects. In that window, any Lovable user with a project link could potentially see them. Researchers reported it through HackerOne from February 22, but the reports were closed instead of escalated. After a researcher went public on April 20, Lovable shipped a fix within two hours and is making current public projects private. Lovable says private projects and Lovable Cloud were never affected.
• Tenzai research: in its "Bad Vibes" test of five coding agents, run in December 2025, Tenzai found 69 vulnerabilities across 15 apps. It reported that the agents frequently introduced authorization vulnerabilities. On September 30, 2026 it built the same three apps with five models on Base44 and found 254 vulnerabilities across the 15 builds.
• UpGuard, October 1: across about 300,000 domains showing Supabase use, UpGuard found 16,326 databases exposing readable tables, and over half showed signs of personal data. It notes that tables created through the API, which is how coding agents work with Supabase, do not turn on row-level security by default.
• Platform changes: Supabase turns on row-level security by default for tables created in its dashboard. It is also deprecating the legacy anon and service_role keys by the end of 2026 in favour of publishable and secret keys. Lovable's quick security scan now runs on every publish and flags tables without per-record access control. Lovable also says its scans cannot guarantee complete security.

The common causes the researchers name:

• Row-level security turned off, or policies that let everyone through.
• Keys in client code, and public keys treated as if they were secret.
• Login and permission checks that live only in the browser.
• APIs that skip the authorization check, so one user can reach another user's records.

Who is affected

• Apps built with AI app builders or coding agents on Supabase or Firebase, especially when an agent created the tables through migrations or the API rather than the dashboard.
• Apps with exposed Supabase keys: a secret or service_role key in the front-end bundle bypasses every row-level security policy.
• Apps that hide buttons for non-admins but never check roles on the server.
• Lovable users who had public projects between February 3 and April 20, 2026. Lovable says it will contact owners whose projects may have been viewed. If you pasted keys or customer data into chat or code, assume someone else could have seen them.
• Founders who store customer data and have not had anyone outside the build tool review access rules.

What to do now

1. Turn on Supabase row-level security everywhere. Supabase's guidance is to enable it on every table and view exposed through the Data API, then write policies that tie each row to the signed-in user. On older projects, also revoke the default grants to anon and authenticated.
2. Run Supabase's Security Advisor. Fix every rls_disabled_in_public finding first. Supabase's own docs say a table in an exposed schema without row-level security is readable and writable by any role with a grant on it.
3. Search your shipped bundle for keys. Only the publishable key belongs in the browser. If a secret or service_role key is there, rotate it today and move that code to a server or edge function.
4. Test as an outsider. Sign in as one user and request another user's records by ID. Then try with no session at all. If either works, you have the same class of bug as the incidents above.
5. Move permission checks to the server. Database policies or API checks decide access. The interface only decides what to show.
6. On Firebase, replace open rules with owner-based rules, such as allowing reads only when request.auth.uid matches the document's owner field.
7. Rotate secrets that touched a public project, and move off the legacy Supabase keys before they are removed.
8. Get a human review before real customer data arrives. Scanners catch common patterns. They do not read your business rules.

Key dates

1. January 31, 2026Wiz reports the Moltbook exposure; tables secured by February 1.
2. February 2, 2026Wiz publishes its Moltbook research.
3. February 3, 2026the Lovable public-project regression window starts.
4. February 22, 2026first HackerOne report to Lovable.
5. April 20, 2026public disclosure; Lovable ships a fix within two hours.
6. April 22, 2026Lovable publishes its incident response.
7. September 30, 2026Tenzai publishes its Base44 study.
8. October 1, 2026UpGuard publishes its Supabase exposure study.
9. End of 2026Supabase's deadline for deprecating the legacy anon and service_role keys.

How we help with vibe coding security

AI tools build fast, and access control is one of the parts they often get wrong. Our vibe code audit checks row-level security, keys, server-side checks and the outsider test above, then fixes what we find with you. If customer data may already be exposed, go straight to our production incident response. Not sure where you stand? Start with the vibe coding risk check. For the wider picture, see "Is vibe coding bad?", our guide to what breaks when AI code ships. Dates for the Supabase key change and other platform shifts sit in our software end-of-life tracker for startup stacks.