Vibe Coding Is a Security Disaster and Nobody Cares

#Let me get this straight.

People with no coding experience are using AI tools to build and deploy web applications that handle real user data, real payment information, and real business logic. They're shipping these applications to the public internet with no code review, no security testing, and no understanding of what the AI actually built for them.

And we're calling this a revolution.

I'm calling it a mass-casualty event in slow motion.

#The numbers are in. They're horrifying.

RedAccess research found 380,000 AI-built applications deployed without active security oversight. Roughly 5,000 of them had virtually no security at all. Open databases. Exposed API keys. Authentication you could bypass by modifying a URL parameter.

Veracode tested over 100 LLMs on security-sensitive coding tasks. 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities. Not obscure edge cases. The top 10. SQL injection. Cross-site scripting. Broken authentication. The stuff we've been fighting for 20 years.

Independent audits put the number even higher: 40-62% of AI-generated code contains security vulnerabilities.

Georgia Tech's Vibe Security Radar tracked 35 CVEs in a single month directly attributable to AI coding tools. They estimate the true count is 5 to 10 times higher.

And here's the one that really gets me: 20% of AI-generated code references packages that don't exist. The AI hallucinates a package name. Attackers register that name as a malicious package. Developers install it because the AI told them to. They're calling it "slopsquatting" and it's already being exploited in the wild.

#The Moltbook disaster.

In January 2026, somebody launched an AI social network called Moltbook. The founder publicly announced he hadn't written a single line of code. The whole platform was built through AI prompts. No developers. No code review. Just vibes.

Three days after launch, researchers at Wiz Security found a Supabase API key sitting exposed in client-side JavaScript. Row Level Security was completely disabled. The entire database was publicly readable.

Three days. That's how long it took for a fully AI-built application to expose every user's data to the open internet.

The founder didn't leave security off intentionally. He didn't know it needed to be turned on. The AI built a working app and he shipped it. The AI didn't mention that the database was wide open because it was never asked about security. It was asked to build features.

This is the pattern. Every single time.

#Why AI can't do security for you.

AI coding tools are optimized for one thing: making code that works. "Works" means the feature does what you described. It does not mean "works securely." It does not mean "handles edge cases." It does not mean "validates input." It does not mean "configures access controls."

When you tell an AI "build me a login system," it builds a login system. It might not hash passwords properly. It might not prevent SQL injection on the login form. It might not implement rate limiting. It might not handle session tokens securely. It "works" in the sense that you can type a username and password and get in. It doesn't work in the sense that an attacker can also get in.

The AI is a junior developer with infinite patience and zero security awareness. It will do exactly what you ask and nothing more. If you don't ask for security, you don't get security.

The problem is that the people using vibe coding tools are exactly the people who don't know what to ask for. They don't know what OWASP Top 10 is. They don't know what SQL injection is. They don't know what Row Level Security is. That's why they're using AI instead of writing code themselves.

It's a perfect storm: the people who know the least about security are building applications with the least secure tools, deploying them with zero review, and handling real user data.

#"But I'm not a developer, this doesn't affect me."

You use apps built by people like this. Your employees use apps built by people like this. The SaaS tool your team signed up for last month? The booking system for your business? The internal dashboard someone on your team built with ChatGPT?

When an AI-built app that handles your data gets breached because it had no security to begin with, you're the one dealing with the consequences. Not the person who prompted the AI to build it.

And if someone in your organization is building tools with AI coding assistants (and they probably are, whether you know it or not), those tools are touching your data, your network, and your customers.

#What to actually do.

If you're building with AI tools:

• Get a security review before deploying. Even a one-hour review by someone who knows what they're looking for can catch the most critical issues. We do this.
• Use Snyk or Semgrep to scan AI-generated code for vulnerabilities before shipping. Both have free tiers.
• Never deploy a database without configuring access controls. If you're using Supabase, turn on Row Level Security. If you're using Firebase, configure security rules. If you don't know what these are, don't deploy until you do.
• Check your dependencies against Socket.dev. The slopsquatting problem is real. AI hallucinates package names and attackers register them.

If you're a business using AI-built tools:

• Ask your vendors if their product was built with AI coding tools. If yes, ask about their security review process. If they don't have one, reconsider.
• Audit internal tools. If anyone in your organization built an internal tool with ChatGPT, Cursor, Replit, or Lovable, that tool needs a security review before it touches production data.
• Include AI-built tools in your security assessment. They're part of your attack surface now.

If you're just a person using the internet:

• Be cautious with new apps from unknown developers, especially ones that brag about being "built entirely with AI." That's not a feature. That's a warning.
• Check Have I Been Pwned regularly. If you signed up for an AI-built app that got breached, your data might be out there.

#The real problem isn't AI. It's skipping the fundamentals.

I'm not anti-AI. AI coding tools are powerful. They can accelerate development dramatically. But acceleration without security review is just building faster in the wrong direction.

A car without brakes goes fast too. That's not a selling point.

Security is not something you bolt on after you ship. It's not something you "get to later." It's not something the AI handles for you. It's a discipline that requires human judgment, and the people building with AI tools need access to that judgment before they deploy.

If you're building something and you're not sure about the security, talk to someone who is. Before launch. Not after the breach.

#Further reading

• OWASP Top 10 - the vulnerabilities AI keeps introducing
• Snyk Code - free AI code security scanning
• Semgrep - open source static analysis for finding vulnerabilities
• Socket.dev - supply chain security, catches slopsquatted packages
• Supabase Row Level Security - don't deploy a Supabase app without this
• Cloud Security Alliance: AI-Generated Code Vulnerability Surge - the research behind the numbers