# Vibe coding ships the app and the breach with it An AI social network called Moltbook launched in January; its founder bragged he 'didn't write a single line of code.' Three days later researchers found its entire database open to the world — 1.5 million auth tokens, 35,000 emails, private messages. It wasn't a freak accident. Studies keep finding that something like 45% of AI-generated code ships a known vulnerability. The demo is free now. The security review is the part you still can't vibe — and the bill for skipping it is somebody's data. - **Author:** Fedor Chishchin - **Published:** 2026-06-06 - **Tags:** security, methodology, ai-native - **Source:** https://fedorthinks.com/blog/vibe-coding-ships-the-breach --- In January, an AI social network called Moltbook launched to some buzz. Its founder said the quiet part out loud: he ["didn't write a single line of code,"](https://www.infosecurity-magazine.com/news/moltbook-exposes-user-data-api/) he'd built the whole thing with AI tools. Three days later, researchers at Wiz found the entire production database hanging open on the internet — **1.5 million API authentication tokens, 35,000 email addresses, and users' private messages,** readable by anyone who looked. The cause is almost too on-the-nose. The AI-generated code put the database key right in the browser-side JavaScript and never switched on row-level security — the one setting that turns that key from a master key into a harmless label. With it on, the key is safe to expose. Without it, that key is the front door, propped open. The agent wrote code that worked in the demo and was wide open in production, and nobody checked the difference. Moltbook is not a fluke. It's the predictable shape of a much bigger problem, and if you're shipping AI-written code, it's worth understanding _why_ it keeps happening. ## The number nobody wants on the slide The research here is remarkably consistent, and it's bad. Veracode's testing found that [about 45% of AI-generated code introduces a known OWASP vulnerability](https://www.veracode.com/blog/spring-2026-genai-code-security/) — and, damningly, that the security pass rate has sat flat at roughly 55% across two years of supposedly revolutionary model upgrades. The models got smarter at writing code. They did not get safer. It compounds from there. Independent analysis found AI-produced code carries a [2.74× higher vulnerability rate than human-written code](https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/), fails to defend against cross-site scripting 86% of the time, and is vulnerable to log injection in 88% of samples. And it's showing up in the wild: in March alone, Georgia Tech's Vibe Security Radar [logged 35 new CVEs caused directly by AI-generated code, up from six in January](https://thenewstack.io/vibe-coding-could-cause-catastrophic-explosions-in-2026/). The breach curve is bending the wrong way, fast. ## Why the model writes insecure code by default This isn't the model being dumb. It's the model doing exactly what it was asked. You tell an agent "build me a sign-up form" and it does — it makes the form work. Security isn't in the request, so it isn't in the output. The model optimizes for the thing you can see in the demo: the happy path where the right user does the right thing. It has no instinct for the unhappy path, because the unhappy path is invisible. Nobody _watching the demo_ tries to read another user's data, inject a script, or hammer the endpoint. The attacker does that later, when you're not looking. That's the whole trap. The part of software that vibe coding is worst at is exactly the part that doesn't show up in a demo — and security is _all_ unhappy path. The same inverted-logic auth bug showed up in [over 170 production apps](https://modall.ca/blog/vibe-coding-security-risks): the AI wrote access control that blocked logged-in users and gave anonymous visitors full access. It worked fine in the demo, because the founder testing it was logged in. The hole only opens for the person who isn't. ## Security is the review you can't vibe I've written that [cheap code is expensive](/blog/cheap-code-is-expensive) — that the cost of AI code doesn't vanish, it moves downstream to whoever maintains it. Security is the sharpest version of that bill, because it isn't paid by you. It's paid by your users, in their leaked data, and it arrives all at once. None of this means don't use AI to build. I build with agents every day. It means the generation step and the verification step are different jobs, and AI collapsed only the first one. Some non-negotiables, learned the easy way by watching others learn them the hard way: - **Assume every secret the agent placed is in the wrong spot until you've looked.** The Moltbook key in client-side JavaScript is the single most common failure. Grep for keys; move them server-side. - **Turn on the boring guardrails the platform already gives you.** Moltbook died because [row-level security](/blog/agents-need-boring-databases) was off. The protection existed; the agent just didn't enable it. The defaults are your friend — switch them on. - **Test the unhappy path on purpose.** Log out and try to read data. Send the wrong input. Be the attacker for ten minutes, because the model never will. - **Run a real scanner before you ship.** A static analysis pass catches the whole boring 45% — the hard-coded secrets, the missing validation, the classic injection — that the agent cheerfully wrote. ## The honest framing Vibe coding genuinely made building an app nearly free. What it did _not_ make free is making that app safe to put other people's data into — and the gap between those two has never been wider. The demo is the easy 80%. The breach lives in the 20% that no demo ever shows you. So ship fast, sure. But before real users touch it, spend the unglamorous hour being your own attacker. The founder of Moltbook skipped that hour and made headlines for the worst reason there is. The hour is cheap. The breach is not.