My Vibe-Coded App Got Hacked: What to Do Right Now

I have never had an app of mine broken into. I want to say that first, because I am about to give you advice and you should know exactly where it comes from.

What I have had is the thing that happens just before. A stranger looked at something I built, told me it was wide open, and I had genuinely no idea. The feeling I remember is not fear. It is embarrassment, and then a quiet awful arithmetic of working out how many other people had already seen it and said nothing.

If someone has actually got in tonight, you are well past that feeling and you need to do things in a particular order. So let me be useful for ten minutes, and we can talk afterwards.

One thing before we start. You are not an idiot and you were not lazy. You described what you wanted, the agent built it, the tests passed, the deploy went green. Somewhere in there was a diff you approved at one in the morning without reading every line, and I have done exactly that, on my own product, with ten years of experience behind me. This is not a character flaw. It is what the tools are like right now.

The first hour

The most common mistake tonight is spending this hour trying to work out what happened. Understanding can wait until nine in the morning. Stopping it cannot.

• Change every key, not just the one you think leaked. Database, payments, any token sitting in your environment variables. You do not know yet what they have, so treat all of it as theirs. Fifteen minutes, and it is the best fifteen minutes you will spend tonight.
• Shut the database. If a table was readable, turn the rules on now, even if it breaks your own app for an hour. A broken app is an annoyance. An open one gets worse every minute. If you are not sure how, take the whole endpoint offline and apologise to people tomorrow.
• Sign everyone out. If someone walked off with a session, this is what takes it back.
• Then stop, and please do not delete anything. I know the instinct. Everything in you wants to tidy up, drop the strange rows, clear the logs, make it look like it never happened. Those logs are the only record of what was actually taken. You are about to need them, possibly legally. Tidying up now is the one mistake tonight that cannot be undone.

Where I would look first

When I go through an app built this way, four things account for nearly everything I find. Worth checking in this order.

A table nobody ever locked

The agent made the table. Unless you asked, it did not decide who is allowed to read it. This is the most common way apps like yours leak and it takes no skill whatsoever to walk through. Someone types your database address into a browser and reads the lot. If you are on Supabase, the Row-Level Security check walks through exactly how to tell.

A key that was never supposed to leave your server

There are two kinds of database key and one of them ignores every rule you have set. If it ended up in the code your site sends to visitors then it has been public since the day you launched. Open your live site, view source, and search it. This is the one that got me, in a slightly different shape, on my own product.

A route that believes what it is told

Agents write endpoints that take an id from the request and hand back that record. It works beautifully when your app asks. It works just as beautifully when a stranger changes the number in the address bar.

An admin page protected by not being linked

If the only thing keeping people out is that there is no button pointing there, it was never protected. Open it in a private window while signed out and see what happens.

Then read your logs, looking for the shape of it. A burst of reads from one place, traffic at an hour you were asleep, one address walking through ids in order. You are answering a single question: what could they have seen?

The bit nobody warns you about

If personal data was exposed, and names and email addresses count, you may have a legal duty to tell people. In Europe that is 72 hours from the moment you knew, and it applies to two people in a bedroom exactly as it applies to a bank.

I am an engineer, not a lawyer, so get proper advice for your own situation. But I will tell you the pattern. Telling people early and plainly is almost always survivable. Being found to have known and stayed quiet is the thing that ends companies. Write it the way you would want someone to write it to you.

What I would do next week

Here is the uncomfortable part, and I would rather say it than not.

One unlocked door usually means the others were never locked either. Not because you were careless. Because whoever built it, human or otherwise, was building the thing you asked for and not the thing you did not know to ask for. That gap is not in one file. It is everywhere the same assumption got made.

So once the fire is out, the useful question stops being how they got in and becomes what else is open right now. The checklist is the version of that you can work through yourself.

If you would rather not do this alone

Send me your app's address. I will go through it myself before we speak, then we take half an hour and I will tell you what I found in normal words. It is free and there is no pitch at the end of it. If you have already shut the door properly I will say so and let you go to bed.