Reported May 2025 · CVE-2025-48757
170 of 1,645 Lovable apps let anyone read the database.
A researcher scanned 1,645 projects from Lovable's public showcase. 170 had Row Level Security missing or misconfigured, exposing 303 endpoints. Because the public anon key is shipped to every browser by design, an unauthenticated visitor could dump names, emails, phone numbers, home addresses, payment details, and third-party API keys straight from Supabase.
Why the AI did not catch it
From where the model sits, the feature works. Row Level Security is a database default it was never asked about, and the anon key is supposed to be public.
What a CTO in your corner catches
First question on any Supabase app: open the network tab, copy the anon key, query the table from the command line. If rows come back, nothing else matters until they do not.
Source: Superblocks: Lovable vulnerability explained
Reported February 2026
The access check was backwards. It blocked logged-in users and let anonymous ones in.
An EdTech app featured on Lovable's own Discover page, built to generate exams and grade students, exposed 18,697 user records including 4,538 student accounts from K-12 schools and universities. A researcher found 16 flaws, six critical. The generated authentication logic was inverted. Lovable closed his support ticket without a response.
Why the AI did not catch it
The tests it wrote tested the happy path. Nobody asked it to log out and try the same request again.
What a CTO in your corner catches
Every access rule is tried from the wrong side before it ships: logged out, logged in as someone else, with a tampered ID. It takes four minutes and it is on the checklist.
Source: The Register, 27 February 2026
Reported July 2025
Base44: a public app ID was enough to register into any private enterprise app.
Wiz Research found that two undocumented Base44 endpoints, registration and OTP verification, required no authentication. Supplying an app_id, which is visible in every app's URL and manifest, let an attacker create a verified account on a private app and walk past SSO. Internal chatbots, knowledge bases, and HR tools were reachable. Wix patched it within 24 hours.
Why the AI did not catch it
This one was the platform, not the builder. The lesson is the same: the vibe-coding platform you build on is part of your attack surface, and you do not get a say in its defaults.
What a CTO in your corner catches
Know which platform flaws you inherit, what their disclosure history looks like, and what you would do the day one is announced. Someone has to read those advisories. It is not going to be you at 11pm.
Source: Wiz: Critical vulnerability in Base44
Composite Names and details invented
Invoice 4471. Then invoice 4472.
Dana's invoicing tool had 600 paying users. An invoice lived at /api/invoices/4471. A customer changed the number to 4472 and got a stranger's client list, hourly rates, and mailing address. Then 4473. She found out from a tweet with a screenshot.
Why the AI did not catch it
The route fetched the invoice by ID and returned it. That is exactly what it was asked to do. Nobody asked "whose invoice?"
What a CTO in your corner catches
Every fetch by ID is scoped to the signed-in owner, in the query, not in the UI. This is the oldest bug on the OWASP list and the single most common one in AI-built apps.
Composite Names and details invented
The admin flag lived in the browser.
Marcus's marketplace decided who was an admin by reading isAdmin from the JWT the browser sent. The token was signed, but the app also let a user edit their own profile, and the profile update wrote every field it received, including role. A user set role to admin, refreshed, and had the dashboard.
Why the AI did not catch it
Two separate features, each fine on its own. The model never saw them together because it was never asked to.
What a CTO in your corner catches
Roles are set by code the user cannot call. Mass assignment is checked on every write endpoint. And the admin panel gets its own review, because it is where the damage is.