Vibe Coding Security Risks Every Builder Needs to Know

Vibe coding security wasn’t on Bob Starr’s mind when he launched ‘Boomberg,’ a small website he’d built with AI assistance to visualise how US tax dollars flow to tech companies. He shipped it fast, felt proud of what he’d made, and moved on. It was only months later that he discovered he’d left a classic SQL injection vulnerability wide open — the kind of flaw that could have let an attacker read or manipulate data they had absolutely no business touching.

• Vibe coding security risks are escalating as more non-developers ship apps handling real user data without safeguards.
• Researchers found roughly 5,000 publicly accessible vibe-coded apps with no authentication, nearly 2,000 leaking sensitive data.
• The biggest danger isn’t amateur builders — it’s personal tools quietly becoming business software nobody secured.
• AI coding tools like Claude Code have security review commands, but users have to actually ask them to run.

When the Fun Stops: Real Stories of Vibe Coding Security Failures

‘It was just a glaring oversight on my part,’ Starr, a project manager in the tech sector, admitted publicly. ‘It was a complete blindspot in my state of learning this new technology and understanding it, and I’m sure there are others making the same mistake.’ He fixed it. But as it turns out, Starr got off lightly.

Jer Crane, founder of PocketOS, posted on X about an AI coding agent that wiped his company’s entire production database. Gone. Joe Procopio, a serial entrepreneur and former developer, vibe-coded a web app to privately demo his other projects. Hackers found it before long, so he pulled it down. ‘Now I do demos the old fashioned way, from my local machine over Zoom,’ he wrote. ‘It’s sooo 2023.’ Painful, but recoverable. Others haven’t been so lucky. Each of these cases is a reminder that vibe coding security failures can hit anyone, regardless of experience level.

The most high-profile case came in late January when a developer named Matt Schlicht launched Moltbook, a viral social network built entirely for AI agents. He wrote zero lines of code himself. Within days, researchers at security firm Wiz found the app’s entire production database sitting wide open on the internet — tens of thousands of email addresses and private messages, completely exposed. Moltbook patched the issue after being notified, but the vibe coding security pattern it represented was far more alarming than any single incident.

Wired subsequently reported that researchers at cybersecurity firm Red Access had found roughly 5,000 publicly accessible apps built with popular vibe-coding tools that had no authentication. Close to 2,000 of those appeared to be actively leaking sensitive data — medical information, financial records, internal strategy documents, and logs of chatbot conversations. That’s not a niche problem. That’s a systemic one.

Vibe Coding Security: Where the Real Danger Lives

It would be lazy to frame vibe coding security as simply a problem of letting amateurs near software. Gabriel Bernadett-Shapiro, a distinguished AI research scientist at AI-powered cybersecurity firm SentinelOne, pushes back hard on that framing. ‘My general core take is that vibe coding is not bad because amateurs can build software,’ he says. ‘That’s actually the good part.’

The danger, in his view, is more specific and more insidious: it’s the moment a personal app quietly drifts into becoming business software, and nobody notices. A tool you built to track your own running stats is one thing. The same app, now storing client data, shared across a team, and handling medical or financial records, is something else entirely — and it needs to be treated that way regardless of how casually it was created. This is precisely where vibe coding security standards tend to break down.

‘Those need to be held to a different standard,’ Bernadett-Shapiro says. ‘Even if it was built by one person in an afternoon. Even if the software creating the software was trivial. The moment that it touches other people’s personal data, then that’s when I think the standard changes.’

Jack Cable, CEO and co-founder of Corridor — a security platform built specifically for AI-native software development — draws a similar line. ‘Vibe coding is great for lower risk things,’ he says, like prototypes or a fitness tracker that doesn’t handle anything sensitive. But once you’re on the public internet, or once financial records enter the picture, the calculus shifts. ‘Are you exposing any of your own or other people’s data there? Think through what the threat model looks like, and if you’re not sure if something you’re doing is secure, better safe than sorry.’ Addressing vibe coding security before launch, not after, is the key discipline Cable is describing.

That advice paid off for Max Segall, chief operating officer at crypto wallet firm Privy. He’d vibe-coded a fun little app called EzRun to reward his kid with $10 in Ethereum every time they went for a run together. Charming idea. But before he launched it, a colleague spotted a critical flaw that would have allowed anyone to modify user accounts and gain access. It got fixed before it ever went live. That kind of pre-launch review is exactly what most builders aren’t doing.

Why AI Tools Won’t Save You Unless You Ask

Here’s the uncomfortable truth at the heart of the vibe coding security problem: the AI won’t stop to ask if what it’s building is safe. In a standard coding session, the build just keeps going. The model generates code, you accept it, and unless you’ve explicitly set something up to catch vulnerabilities, nothing flags them. The security tools that exist have to be actively invoked — they don’t run themselves by default.

Claude Code does include a /security-review command that scans your project for vulnerabilities. But you have to know to ask for it. There’s an automated version, too, but only if you’ve configured it to run on pull requests in advance — the kind of workflow setup that professional developers do habitually and that most casual builders have never thought about.

OpenAI’s Codex has a built-in component called Codex Security, which scans commits as they land and re-scans its own proposed patches. It’s a meaningful step forward, but it’s explicitly aimed at developers with real version-control workflows. It’s not designed for someone who’s chatting an app into existence over a weekend and deploying it straight to the internet. For that audience, vibe coding security remains almost entirely self-directed.

There’s also a subtler psychological risk: when an AI confidently tells you the code looks good, it’s surprisingly easy to believe it. Overconfidence is its own vulnerability. The model isn’t auditing your app against every known attack vector — it’s doing its best based on what you’ve asked it to do. If you haven’t asked about security, it probably hasn’t thought hard about security.

The Bigger Picture: An App Explosion With Security Lagging Behind

None of this means professionally built pre-AI software has been a fortress. Enterprise codebases are riddled with vulnerabilities too — that’s not a new story. But vibe coding security becomes a qualitatively different challenge when you factor in scale. The number of apps being built is growing exponentially. Every day, thousands of people who’ve never thought about threat modelling or input sanitisation are shipping software that touches real data on real servers.

We’re living through what some have called an ‘era of personal software’ — a moment when the ability to build something useful is no longer gated by years of programming experience. That democratisation is genuinely exciting. But it comes with a responsibility gap that the tools themselves haven’t fully closed yet.

The practical advice is straightforward even if it requires discipline: prompt explicitly for vibe coding security at the start of every build session, and again at the end. Ask your tool to review what it’s created. Think about who can reach your app, what data it stores, and what happens if someone malicious finds it first. The AI is a powerful collaborator, but it’s not your security team. Until the tools get better at volunteering that analysis unprompted — and they will, eventually — that job is still yours.

Source: The Verge

Frequently Asked Questions