Four vibe coding security failures in 90 days. Here's what they have in common.

I've been writing code for 20 years. Now I use AI tools in my workflow every day. And I'll be honest with you: I'm writing this because I looked at these four incidents and recognized some of my own habits in them.

Lovable. Moltbook. Vercel. Anthropic. Between January and April 2026, all four made the news for security failures. None of them involved a sophisticated attacker. None of them required a zero-day exploit. The vulnerabilities were basic. The data was sitting in plain sight.

The pattern isn't "AI writes insecure code." The pattern is something more specific and more uncomfortable: when everything moves fast and everything is automated, the security review is the first thing that falls off. Not by decision. By default.

What actually happened

Let me go through each case briefly. If you want the quick visual version, I also made a carousel about this on Instagram. Same data, no text wall.

Lovable is an AI vibe coding platform used by enterprise teams. Between late 2024 and April 2026, any free-tier account could access source code, database credentials, AI chat histories, and customer data from any project created before November 2025. A security researcher discovered this and reported it to HackerOne. HackerOne classified the report as a duplicate. Left it open. For 48 days. Lovable's initial response, when the story finally broke in April 2026, was that the behavior was "intentional." Then they blamed HackerOne. Among the companies using Lovable at the time: Uber, Zendesk, Deutsche Telekom.

Moltbook is an AI social network built by Matt Schlicht. In January 2026, Wiz Research discovered that the entire production database was readable by anyone, unauthenticated, without any credentials. The Supabase API key was hardcoded in the client-side JavaScript. Row Level Security was disabled on every table. Wiz found it in minutes during what they described as a "routine scan." The breach exposed 1.5 million authentication tokens and 35,000 email addresses. Some of the private messages between AI agents contained OpenAI API keys in plaintext. Schlicht's public statement after building the app: "I didn't write a single line of code. AI made it a reality."

Vercel had an employee connect a third-party integration called Context.ai without reviewing what OAuth permissions that connection was granting. Context.ai was itself compromised. The result was a supply chain attack that exposed customer API keys and environment variables from a subset of Vercel customers. A threat actor group called ShinyHunters claimed the data and listed it on BreachForums with a $2 million asking price. This happened in April 2026.

Anthropic shipped version 2.1.88 of the @anthropic-ai/claude-code npm package on March 31, 2026, without reviewing what was bundled inside it. A 59.8 MB source map file contained 513,000 lines of TypeScript across 1,906 files. The entire internal source code of Claude Code was public. The package was mirrored to GitHub and forked thousands of times before it was pulled. Two CVEs followed: CVE-2025-59536 (remote code execution) and CVE-2026-21852 (API key exfiltration), documented by Check Point Research.

The thing they all share

I want to be precise here, because I think the imprecise version of this argument is wrong.

The imprecise version is: "AI-generated code is insecure." That's not what the evidence shows. Experienced engineers misconfigure Supabase. Experienced engineers have shipped npm packages with things they shouldn't have. Supply chain attacks through third-party OAuth integrations have happened at companies with no AI in their stack at all.

So what's the actual pattern?

All four of these failures happened at the review step. Not at the writing step.

The Moltbook database wasn't readable because an AI wrote the code. It was readable because no one checked whether Row Level Security was enabled before shipping to production. The Supabase API key was in the client bundle because no one ran the bundle through a secrets scanner before publishing. The Vercel integration was compromised because no one audited the OAuth scopes before approving the connection. The Anthropic npm package shipped with source maps because the deploy process didn't include a step that validated what was in the package.

When everything moves fast, and when the model writes code that works on the first try more often than human memory says it should, the psychological impulse to skip the review step is enormous. The code runs. The tests pass. What could be wrong?

This is the thing that 20 years in the industry teaches you. Not that you should write more secure code. You should, but that's table stakes. The real lesson is that you've been burned enough times to know that "it works" and "it's safe" are two different questions.

What experience actually gives you

People talk about experience as if it makes you faster. Sometimes it does. But the part that matters more is that it makes you slower in the right places.

You learn which gates you don't skip. Not from reading about them. From almost missing them yourself.

The model doesn't have that. This is not a criticism of the model. It's a description of what the model is. It's a prediction engine. It generates the most likely next token given the training data and the context window. When you ask it to build an authentication system, it will build one that looks correct. It will implement the Supabase client. It will write the auth flow. It will not, on its own initiative, pause to ask: "Wait, is Row Level Security enabled on this database?" That question doesn't come from the training data. It comes from having been the engineer who shipped without checking it and then had a very bad week.

The model has no skin in the game. It doesn't lose sleep over a breach.

My actual workflow

I want to be specific here, because this post is not useful if it ends at "be more careful." Careful is not a workflow.

I use vibe coding in my own projects. Hikari, my iOS app, uses AI-assisted code for significant parts of the implementation. The content pipeline that runs this blog is built on Claude Code with 51 specialized agents. I am not arguing against the tool.

Here's what I don't let the model own unsupervised, regardless of how good its output looks:

Auth flows and session management. I review every line. I trace the token lifecycle manually. I check expiry, rotation, and what happens at the edges.

Row Level Security and database permissions. For every table, I verify RLS is enabled and I read the policies out loud before pushing. "Any authenticated user can read their own rows" sounds fine until you realize your query is using the service role key.

Environment variables and secrets. Before any deploy I check for any service keys or API credentials in the build output. I check that .env is in .gitignore. I check that the build output doesn't contain anything it shouldn't.

Third-party OAuth integrations. I read the permission scope before approving. Every single one. "Read access to your data" is a very different grant than it sounds.

These are not exotic security practices. Every single one of these gates directly corresponds to one of the four failures above. Lovable: authorization review. Moltbook: RLS check plus secrets scan. Vercel: OAuth scope audit. Anthropic: package contents validation before publish.

The model will not do these for you unless you explicitly prompt it, and even then you should verify its output rather than trust it. Not because the model is careless. Because the model is optimizing for "code that works" when you need "code that's safe."

The tools are for using with supervision

I'm not writing this to scare you away from vibe coding. I'm writing this because I think the conversation happening around these incidents is often wrong in one of two directions.

One direction: "AI is going to destroy security." It's not. The tools are getting better. Supabase has a built-in RLS reminder. Cursor flags hardcoded secrets. npm has secret scanning. The tooling ecosystem is catching up.

The other direction: "These are implementation failures, not vibe coding failures. Experienced engineers misconfigure databases too." True. But this misses the point. The velocity that vibe coding enables creates a specific pressure on the review step. When the model generates a working implementation in seconds, the natural human impulse is to treat that speed as permission to skip the validation. That's the failure mode. Not the code. The rhythm.

What 20 years gives you is a stubborn resistance to that pressure. You've felt the pull to skip the check. You've done it. You know what the other side of that decision sometimes looks like.

If you're new to building and you're using AI tools heavily: you don't have those scar tissues yet. That's not a judgment. It's just true. The answer isn't to avoid the tools. The answer is to find the people who have been burned and ask them where they check before they push.

The checklist above is my version of that. It's not complete. Your stack will have its own sharp edges. But the principle is: the model writes the first draft, you own the review.

Save this post for the next time you're about to deploy a vibe-coded project. Run down the list. It takes 10 minutes. It's not the tools that fail. It's the absence of the reviewer.