Lovable app hacked / the first hours
Your Lovable app got hacked. Here is the next few hours.
Maybe a stranger emailed you a screenshot of your users table. Maybe a researcher posted about it. Maybe you ran a check and your stomach dropped. First, the thing nobody says: this happens to a lot of Lovable apps, and it is not because you are careless. It is not your fault. It is, however, your problem now, and the next few hours matter more than the next few weeks.
The short answer
Do not panic and do not delete anything. If data is actively exposed, take the app private or pause signups. Rotate every key an attacker could have seen, starting with the Supabase service role key. Preserve logs and timestamps. Then work out what was actually reachable before deciding who to tell.
The first hour: stabilize without destroying evidence.
Everything in this hour is reversible or protective. Nothing in this hour is a fix. Fixing comes later, once you know what you are fixing.
One note on the anon key, because it confuses everyone: the Supabase anon key is meant to be public, so finding it in your page source is not the breach. The breach is what that key was allowed to do. If row-level security was off, the anon key was functionally a master key, and you should treat everything it could reach as exposed.
The four places Lovable apps actually leak.
Once the bleeding is stopped, check these in order. Across the public incident record for Lovable-built apps, the overwhelming majority of real leaks trace to one of these four surfaces.
Lovable ships built-in security scanners, and they are worth running. But Lovable's own documentation is direct about their limits: the security overview states that the scanners "do not replace a thorough security review" and that you are responsible for your app meeting the security requirements of its use case (as of July 2026). After an incident is exactly when that distinction matters. For the calmer, pre-incident version of this check, see is Lovable safe.
Blast radius: what was reachable, and for how long.
Two questions define your incident, and everything you owe your users flows from the answers. What data was reachable? And for how long?
What was reachable. For every table without a working RLS policy, list the columns and ask what they contain: emails, names, addresses, payment identifiers, messages, anything about children or health. Do the same for public storage buckets and for anything an unauthenticated edge function would return. Be honest with the list; you are writing it for the version of you that talks to a lawyer.
For how long. The exposure window opens when the misconfiguration shipped, not when you noticed. Find when the table was created or the bucket made public, then use Supabase API logs to look for actual suspicious reads inside that window. Logs can shorten the story from "exposed for three months" to "exposed for three months, with evidence of one read by a researcher who reported it." That difference changes the notification conversation entirely.
Two limits to respect: log retention on lower Supabase plans is short, so the absence of logs is not the absence of access. And "reachable" is not the same as "taken." Write down both what you can prove and what you cannot rule out, with timestamps. That document is the backbone of everything that follows.
Telling your users: the part everyone wants to skip.
First, the flag: this is not legal advice, and breach notification law genuinely varies by jurisdiction. If personal data was plausibly exposed, a short conversation with a lawyer belongs in your first day, not your first month.
The plain-language version of the landscape: if you have users in the EU or UK, the GDPR expects qualifying breaches to be reported to the regulator within 72 hours of you becoming aware, with affected users informed when the risk to them is high. In the US, notification duties come from state laws that differ in what counts as personal information and how fast you must move. Other countries have their own regimes. Where your users live matters more than where you do.
Whatever the law requires, the human version rarely goes wrong: tell affected users what was exposed, when, what you have done about it, and what they should do, in plain sentences, without euphemism. "We take security seriously" convinces no one. "Email addresses and order histories were readable between March and June; passwords were not; we have closed the hole and here is how we verified it" earns back more trust than silence ever protects.
After the fire: proof it is closed, and someone watching.
Verify with a re-runnable proof, not vibes. Keep the exact request that leaked data and run it again after the fix: the curl against the REST API, the console snippet, the bucket URL. Closed means that request now fails, and keeps failing after every future deploy. "The scanner is green now" is not verification; scanners check for the presence of protections, not whether your specific hole is shut. This is the standard our own work is built around: a Ship Check ($299 flat) audits the whole app and attaches a re-runnable proof to every finding, and a Ship Fix ($4K to $15K by scope) closes the dangerous ones with the same proof attached. You can see how that has gone for other founders on the proof page.
Then decide who watches it. Here is the uncomfortable pattern behind most second incidents: a one-time fix with nobody watching afterward is how you end up back on this page. The app keeps changing, you keep prompting, and every change can quietly reopen a surface. What prevents the sequel is not a bigger fix, it is a watcher: a named person responsible for the app between incidents, with checks that re-run on every change. That can be a developer you trust, or an ongoing arrangement like Continuum, which runs from $49 to $199 per month for Watch, $500 to $1,500 per month for Care, and $3,000 to $15,000 per month for Partner. What ongoing upkeep should cost, and why, is a topic we treat honestly in what SaaS maintenance actually costs.
And to be plain about the alternatives, because a hacked founder deserves options, not a funnel: Lovable support can help with platform-side questions, any competent security engineer can work this playbook with you, and fixed-price rescue shops exist, for example Afterbuild Labs offers a $299 Emergency Triage for a single broken production issue (as of July 2026). If your original developer has disappeared mid-incident, we wrote a guide for exactly that, and when you are ready to hand the app to someone who stays, start with the vibe code handoff guide.
You are not the first. The public record, dated.
If it helps to know the scale of the company you are in: this is the verifiable public timeline of security incidents around Lovable and its category. Every entry links to its source.
The takeaway is not that Lovable is uniquely dangerous. It is that the category ships working apps to people who were never told which switches matter, and the incidents keep arriving on a steady cadence. The founders who come through them well are the ones who moved calmly in the first hours, kept their evidence, and put a watcher on the app afterward.
Hacked-app questions, straight answers.
You do not have to
work this list alone.
And if the right move is Lovable support or an engineer you already trust, we will say so.
Matt
Last updated: July 2026