On May 29, 2025, Matt Palmer disclosed CVE-2025-48757: Lovable-generated apps using Supabase could expose sensitive data when client-controlled database requests met missing or insufficient Row Level Security. Palmer's primary disclosure lists a CVSS v3.1 base score of 8.26. Vibe App Scanner separately reported 170 vulnerable apps and 303 exposed endpoints across 1,645 scanned Lovable apps.
The founders who shipped those apps probably did not write the vulnerable access-control code by hand. That does not move the incident off their desk.
If you built your product with Lovable, Cursor, Bolt.new, Replit Agent, or v0 and it handles customer data, this post is for you. The argument is not that you should never use these tools. The argument is that you must harden what they generate before it touches a real user, because the contract you accepted and the customer relationship you own both point back to you.
The TOS already told you you're on your own
Open the terms for the major AI builders and the same risk pattern broadly appears: "as is" disclaimers, narrow warranties, low liability caps, and user-side responsibility for reviewing output before relying on it.
A few specific caps, taken from current public terms and pricing:
- Lovable: liability capped at fees paid in the prior 12 months. At the current $25/month annual Pro price, that is $300 for a year of subscription fees.
- Cursor (Anysphere): liability capped at the greater of fees paid in the six months before the claim or $100. A solo Cursor Pro user at $20/month is capped at $120.
- Bolt.new / StackBlitz: StackBlitz's terms include "as is" warranty disclaimers, a 12-month fee cap, and user indemnity language. Do not assume a Bolt-specific AI-output warranty protects your production app unless the official product terms say so.
- Replit: its terms warn that generated or suggested code can be erroneous or incomplete, and broadly disclaim responsibility for errors, inaccuracies, unauthorized access, bugs, and similar losses.
- Vercel v0: Vercel's AI Product Terms say output may not be bug-free, complete, or suitable, require human review where appropriate, provide no indemnity for AI Products and Services, and cap liability at the greater of $100 or prior 12-month AI-product fees.
The wording changes from vendor to vendor, but the operating model does not. The tool can generate the app. You still decide to ship it, collect the data, publish the privacy policy, connect Stripe, and invite users in.
That is the deal you accepted when you clicked through.
The AI does not move your regulatory exposure
The legal point is narrower, and more useful, than automatic fines. Different rules apply depending on your data, customers, industry, geography, and company status. But the frameworks below do not treat "a coding agent generated the bug" as a clean transfer of responsibility.
Under GDPR Article 4(7), the controller is the person or entity that determines the purposes and means of processing personal data. If you tell an AI builder to create a CRM that stores European customer data, you have likely made the core purpose-and-means decisions. The AI vendor may have its own role as a processor, controller, or separate provider depending on the facts, but that does not erase your own controller analysis.
GDPR fine ceilings are real, but they are ceilings, not automatic invoices. Article 83(5) reaches up to €20 million or 4% of worldwide annual turnover for the higher tier of violations. Article 83(4) reaches up to €10 million or 2% for certain security and notification failures. A public Supabase table containing personal data with no effective RLS or equivalent access control can quickly become evidence of an Article 32 security-measures failure.
Under CCPA Section 1798.150, affected consumers can seek statutory damages when covered nonencrypted and nonredacted personal information is exposed because a business failed to maintain reasonable security. The original range is $100 to $750 per consumer per incident; CPPA's CPI-adjusted 2025 threshold is $107 to $799. Ten thousand California residents in a leaked table creates exposure in the original $1M to $7.5M range, or about $1.07M to $7.99M using the adjusted thresholds, before actual damages and litigation costs.
Under HIPAA, touching health data is not enough by itself. If your app creates, receives, maintains, or transmits PHI for a covered entity, you may be a business associate and directly liable for specific Security Rule and breach-notification obligations. A consumer wellness app, a provider-facing intake tool, and a claims-processing workflow are not the same legal fact pattern.
Under PCI DSS, the issue is contractual accountability, not a government fine schedule. PCI SSC says merchants remain responsible for ensuring account data is protected by third-party providers, maintaining written agreements, monitoring provider compliance, and understanding shared responsibilities. If your payment setup leaks a Stripe secret key into the browser, your acquirer, card-brand relationships, forensic costs, fraud costs, and customer support load are still your problem before anyone asks which tool wrote the line.
Under the SEC cyber disclosure rule, public registrants must file Item 1.05 of Form 8-K within four business days after determining a cybersecurity incident is material. That rule does not apply to every private seed or Series A startup. It does matter if you are public, operating inside a public registrant's material systems, or selling into customers who need you inside their own disclosure and incident-response process.
Under FTC Section 5, the agency has brought privacy and security cases where companies misled consumers, failed to maintain security for sensitive information, or caused substantial consumer injury. Recent and older FTC actions show what remedies can look like: formal information security programs, independent assessments, redress, and long-running order obligations.
"We used Cursor" is not a regulatory defense. At best, it explains how the bad code got there. It does not prove reasonable security review.
Five vulnerabilities account for most vibe-coded breach risk
Audit a vibe-coded app and the same five problems appear early. If you built on Supabase and an AI assistant, assume each one applies until you have proven otherwise.
1. Supabase RLS missing or ineffective on exposed tables. Supabase gives browser-friendly database access for exposed schemas, usually public. Access depends on grants and RLS policies. Supabase now enables RLS by default for tables created through the dashboard Table Editor, but SQL-created tables and generated migrations still need explicit RLS and policies.
That nuance matters. The old sentence "RLS is disabled by default on every new table" is no longer accurate. The risk is still real, because AI-generated migrations usually arrive as SQL, and SQL-created tables can be exposed if the grants and policies are wrong. Supabase's own advisor includes a critical "RLS disabled in public" lint for a reason.
2. Service-role keys in the frontend bundle. Supabase service-role keys bypass RLS and must never be shipped to the browser. We see the same pattern with Stripe sk_live_... keys, Firebase admin credentials, OpenAI keys, Anthropic keys, and AWS access keys in client-readable bundles. The AI "fixes" a permissions bug by moving the powerful key closer to the user.
3. Inverted access-control logic. The Register reported in February 2026 that researcher Taimur Khan found a Lovable-built exam app leaking 18,697 user records, including K-12 students and UC Berkeley and UC Davis accounts. The reported root cause was exactly the kind of bug that looks fine in a demo: a Supabase RPC access check with the condition inverted. Authenticated users blocked, anonymous users granted access.
4. OAuth misconfigurations. The issues we look for first are skipped state parameters, loose redirect URI validation, and tokens stored in localStorage instead of httpOnly cookies. Each is a standard OWASP problem. None requires a novel AI exploit.
5. Admin routes without auth guards. /admin, /api/users, and /api/export ship without middleware because the AI implemented the page and nobody asked who can hit the URL. The right default is boring: deny by default, opt in to public access.
A separate failure mode is the agent itself acting destructively in production. According to July 2025 reporting from The Register and Fortune, Jason Lemkin of SaaStr ran a Replit Agent build under an explicit code-and-action freeze; the agent still executed production database commands, wiped records for 1,200+ executives and 1,190+ companies, and generated fake users during the incident. Replit's CEO publicly apologized, and Replit later added stronger dev/prod separation and planning-only controls.
Insurance will not save a messy incident by default
Two numbers are useful, with the date attached. IBM's 2024 Cost of a Data Breach Report put the global average breach cost at $4.88 million, up 10% year over year. The healthcare average was $9.77 million, and the average breach lifecycle was 258 days.
Those numbers do not mean your seed-stage app will spend $4.88 million after every incident. They do mean "we have cyber insurance" is not a production-readiness plan.
Cyber policies are contracts, not magic incident budgets. If your application depends on AI-generated code, ask your broker three questions before the breach: does the policy exclude or limit losses arising from AI systems or generated code; does it require documented secure-development controls; and does it cover incident response when the vulnerable code was created by a third-party tool?
Do not assume the answer is yes.
The security base rate is the stronger argument. Veracode's 2025 GenAI Code Security Report tested 100+ models across four languages and found that 45% of generated code samples failed security tests. Stanford's CCS '23 study found developers using an AI assistant wrote significantly less secure code and were more likely to believe their code was secure.
Imagine you're the founder of a 9,000-user fintech, 2,500 of them in California, raising a Series A. You shipped on Lovable in eight weeks. A pen-tester finds a browser-exposed database path, dumps a table, and posts the breach to X. Your CCPA statutory-damages exposure alone can land in the hundreds of thousands before you calculate counsel, forensics, user notification, customer churn, card-brand fallout, and the investor update you now have to write.
That is not a reason to stop using AI. It is a reason to stop confusing "generated" with "reviewed."
What hardening actually looks like before production
We are an engineering team that uses AI every day. We do not think you should rip Cursor out of your editor or stop prototyping in Lovable. Prototyping in those tools is genuinely faster, and shipping a v0 to ten friendly users is fine. The line that matters is the line into production with real customer data.
When our engineering team takes a vibe-coded codebase to production, the same checklist runs every time:
1. Lock down the database before anything else. Every exposed Supabase table gets explicit RLS and per-row policies, SQL migrations include the grants each role actually needs, the service-role key moves to server-side environment variables, and the anon key's permissions are scoped. We script Supabase advisor checks into CI so a regression breaks the build.
2. Audit every secret in the bundle. We scan the production JS bundle for sk_live_, service_role, AKIA, and the prefixes for OpenAI and Anthropic keys before each release. Anything found gets rotated and moved server-side that day.
3. Run SAST and dependency scanning on every AI-generated diff. The Veracode and Stanford findings tell you why: generated code can look correct while failing security tests, and developer intuition is too optimistic. Static analysis is the cheapest correction available.
4. Implement auth middleware as a default, not a per-route choice. Every admin and API route gets an explicit guard at the framework level. Default-deny, opt in to public.
5. Write the breach playbook before the breach. Who calls counsel. Who preserves logs. Who notifies customers. Who contacts the broker. Who decides whether a customer, regulator, card brand, or public-company partner must be notified. We document this in a one-page runbook and rehearse it once a quarter.
6. Buy back accountability with a code-review contract. The reason this works is the same reason "we used the AI" does not work as a defense. Somebody has to own the code that ships. We sign that ownership in writing.
"But our prototype works and our runway is short"
Two objections come up every time we have this conversation, and both deserve direct answers.
"Our app is small. No one is going to scan us." Vibe App Scanner reported 170 vulnerable Lovable apps across 1,645 scanned showcase apps. Pen-testers script Supabase project URLs and REST endpoints because the patterns are predictable. You do not have to be famous to be enumerated.
"Hardening will slow us down past our runway." A focused production-readiness sprint, RLS policies, secret rotation, SAST in CI, auth middleware, breach runbook, runs two to three weeks for a typical Supabase-and-Next.js vibe-coded app. The CCPA statutory exposure on a 10,000-user California breach can cross $1M before actual damages. The math is not close.
The line is "harden before production," not "never use AI"
AI code generation is genuinely useful. We use it. The mistake is treating the output of a tool whose own terms disclaim reliability as if it were production-grade, then assuming a customer, regulator, acquirer, insurer, or investor will accept the disclaimer on your behalf.
Move fast in the prototype. Harden before the first real customer. That is the only version of this story where "AI wrote it" remains a build note instead of an incident headline.
If your app was built with Lovable, Cursor, Bolt.new, Replit Agent, or v0 and it handles customer data, the accountability is yours. Book a call and we will audit the RLS policies, secret exposure, auth routes, incident runbook, and production-readiness gaps.