Vibe Coding Is Fast But Is It Safe? Security Risks You Can't Ignore (June 2026)

The Tea app vibe coding Reddit threads exploded after users found their private messages were exposed to strangers. That wasn't a particularly sophisticated attack or a supply chain compromise; it was AI-generated code that shipped without security review, and it's part of a larger pattern. From the Tea app data breach to vibe coding hacked endpoints like Moltbook's open admin route, we're seeing the same vulnerability classes appear again and again. Here's how to spot vibe coding security risks before they become your next incident response.

TLDR:

• 38% of AI-generated code contains security flaws like injection vulnerabilities and hardcoded secrets.
• LLMs hallucinate fake package names 20% of the time, creating slopsquatting attack opportunities.
• The Tea app leaked user DMs through broken access control logic generated by AI without review.
• Iterating with AI increases critical vulnerabilities by 37.6% instead of fixing existing flaws.
• Arnica automates security checks on AI-generated code to catch hardcoded secrets and risky dependencies.

What Is Vibe Coding and Why Is It Everywhere Right Now?

Vibe coding is building software by describing what you want in plain language and letting an AI generate the code. You prompt, the AI writes. The developer's role moves from author to director.

That shift has reached critical mass. According to the Stack Overflow 2024 Developer Survey, 92.6% of developers use an AI coding assistant at least once a month, and roughly 75% do so weekly. The speed gains are measurable: an enterprise developer productivity study found developers using AI completed tasks about 21% faster, which is exactly why adoption has outrun the security controls built to govern it.

The Vulnerability Numbers You Need to Know

AI-generated code contains security vulnerabilities at rates that should give any engineering leader pause. A January 2025 study found that 38% of AI-generated code contained at least one security flaw, spanning injection vulnerabilities, hardcoded secrets, and broken authentication. GitHub disclosed that Copilot suggestions were vulnerable in roughly 30% of security-sensitive scenarios. That's not a theoretical edge case. That's a systematic pattern.

The Tea App Incident: When Vibe Coding Meets Real Users

The Tea app became one of the most-discussed vibe coding incidents of 2025. The app, built largely with AI-assisted code generation, exposed private user direct messages to other users due to broken access control logic that the AI generated without any security review. Screenshots of the leaked DMs spread quickly across Reddit, with threads in r/privacy and r/programming dissecting how the breach happened and what it revealed about vibe coding risks more broadly. The Tea app incident is now a reference point in conversations about vibe coding security on Reddit, where developers debate whether speed-to-ship culture is fundamentally incompatible with protecting user data.

The Moltbook Breach: Zero Lines of Code, Maximum Exposure

The Moltbook incident is one of the clearest examples of what can go wrong when AI-generated code ships without proper review. A developer used an LLM to build a MacBook resale app called Moltbook, and the AI quietly generated a publicly accessible admin endpoint with no authentication. No malicious intent. No complicated exploit chain. Just an open door that anyone with a browser could walk through.

User data was exposed before the developer even realized the endpoint existed.

This is the pattern security teams should be watching for: not sophisticated attacks, but basic misconfigurations that slip through because the developer trusted the output without questioning it. LLMs are optimized to produce code that works, not code that's safe. An unauthenticated admin route satisfies the functional requirement. It fails the security one.

The Moltbook case is a useful anchor because it strips away complexity. There was no malware, no insider threat, no supply chain compromise. Just generated code, no security check, and real user exposure as a result.

Common Vulnerabilities AI Models Keep Generating

LLM-generated code carries well-documented vulnerability patterns that security teams are already tracking. The OWASP Top 10 for LLMs identifies insecure output handling, prompt injection, and training data poisoning as top concerns. GitHub Copilot generates insecure code in a majority of cases when tested against security-sensitive scenarios, and AI-assisted code introduces copy-pasted code duplication at rates far higher than human-written code, increasing attack surface in ways that are difficult to audit.

The Vulnerability Classes That Keep Showing Up

Several categories appear repeatedly in vibe-coded outputs:

• Hardcoded credentials and API keys left embedded in source files, often because the AI is optimizing for working code instead of secure code.
• SQL injection and command injection vulnerabilities generated when AI models follow input patterns without applying sanitization logic.
• Insecure direct object references and broken access controls that appear in CRUD applications where the model skips authorization checks entirely.
• Overly permissive CORS configurations and missing security headers that ship straight to production when no one reviews the output.

No single vulnerability class dominates. The risk is spread across the stack, which makes point-in-time scanning insufficient on its own. Real-time SAST is needed to catch issues as they're introduced.

Hallucinated Dependencies and the Slopsquatting Threat

LLMs don't just generate vulnerable code. Sometimes they invent the dependencies it relies on.

The Cloud Security Alliance's April 2026 slopsquatting research note quantified the problem: across 2.23 million AI-generated code samples from 16 models, 19.7% contained at least one hallucinated package name that doesn't actually exist. The security problem is the follow-on finding: 43% of those hallucinated package names reappeared on every single run when the same prompts were repeated.

Consistent hallucinations are predictable. Predictable names are registerable.

That's slopsquatting. Attackers identify the phantom package names that LLMs reliably generate, publish malicious code under those exact names, then wait for developers to run the install command their AI assistant just wrote. The developer runs npm install or pip install and pulls attacker-controlled code directly into their project, no exploit required. Security teams scanning for known malicious packages won't catch a hallucinated dependency that didn't exist until an attacker created it. Package reputation monitoring helps identify these risks.

Security Degradation Through Iteration

Each iteration doesn't clean up the last one. It compounds it.

A published IEEE-ISTAS controlled experiment measured a 37.6% increase in critical vulnerabilities after just five rounds of AI-assisted code refinement. The model doesn't self-correct flaws on subsequent passes. It buries them deeper.

Why Traditional SAST Tools Miss AI-Generated Risks

Traditional SAST was built to recognize known-bad patterns: dangerous function calls, known injection sinks, flagged API usage. A call to eval() with unsanitized user input fires an alert. A route with missing authorization logic that compiles cleanly does not.

The vulnerability lives in what's absent. AI-generated code produces this class of problem repeatedly: insecure parsing assumptions, missing auth checks on functional endpoints, unsafe defaults that no pattern matcher knows to flag. The code passes syntax checks. The security failure is semantic, and signature-based tools have no signature to match against a missing decision.

Three structural gaps explain why pattern-matching falls short on AI-generated code:

• Missing controls have no signature. A scanner can flag a dangerous call, but it can't flag an authorization check that was never written. The Tea app and Moltbook breaches were both absent-control failures, not bad-pattern failures.
• The risk spans multiple files. AI often generates an endpoint in one file and the access logic in another. Single-file pattern matching can't reason across that boundary to see that the two never connect.
• Functional code masks intent gaps. The model optimizes for code that runs, so the output compiles, passes tests, and ships. Whether it enforces your tenant isolation or data-handling rules is a question a signature can't answer.

Closing these gaps takes AI SAST that reasons about intent and data flow across files, not just a larger rule set. Arnica's AI Generated mode looks beyond rule matches to find multi-file data exposure, authorization gaps, and insecure business logic that pattern-only scanners miss, and security operators can steer it with plain-language prompts like "look for tenant isolation risks" without authoring scanner rules.

Prompt Injection Attacks Against AI Coding Tools

Vulnerabilities in the generated code are one problem. AI agents reading your codebase create another attack vector.

Coding assistants like Cursor and GitHub Copilot pull context from external sources: READMEs, open GitHub issues, inline comments, documentation files. Attackers have found a way to abuse that behavior. By embedding hidden instructions inside those files, they can redirect what the agent does next. The technique is called indirect prompt injection, and a January 2026 meta-analysis of 78 studies on agentic coding assistants like Claude Code, Cursor, and GitHub Copilot found that attack success rates exceed 85% when adaptive attack strategies are used, and that most published defenses block less than 50% of those attacks. The injected commands included SSH key exfiltration and privilege escalation sequences.

The agent reads a poisoned README. It follows the embedded instruction. The developer watching the output sees code being written, not an attack in progress.

The False Confidence Problem

Vibe coding tools generate code fast, and that speed feels like validation. When an AI writes 300 lines in seconds, it's easy to assume the output was checked. It wasn't. The model has no awareness of your threat model, your compliance requirements, or your infrastructure. It simply predicts what code should look like next.

This gap between perceived safety and actual risk is where incidents happen.

The CVE Attribution Surge

The "Vibe Security Radar," a project run by researchers at Georgia Tech's Systems Software & Security Lab (SSLab), tracks CVEs with direct attribution to AI-generated code. The monthly count has climbed steadily through 2026, offering one of the clearest signals yet that vibe coding incidents are moving from anecdote to documented record.

How to Vibe Code Without Getting Hacked

Security starts with awareness. These four practices directly target the vulnerability classes covered above, broken access controls, hardcoded secrets, hallucinated dependencies, and prompt injection, when using AI-assisted coding tools:

• Treat AI-generated code like unreviewed third-party code: read it, test it, and run static analysis before merging. Implement real-time secret detection to catch credentials before they're committed.
• Never paste secrets, credentials, or sensitive architecture details into an AI prompt.
• Keep a human in the loop for any code touching authentication, authorization, or data storage.
• Audit your dependencies. AI tools frequently suggest packages that are outdated, abandoned, or malicious.

Governing AI-Generated Code at Scale With Arnica

Vibe coding moves fast. The appeal is obvious: describe what you want, get working code, ship it. Speed without guardrails creates exposure at a scale most security teams aren't prepared for.

Arnica sits at the intersection of developer workflow and security policy, giving AppSec and engineering teams visibility into AI-generated code before it reaches production. Instead of relying on developers to self-police, Arnica automates security checks across repositories, catching hardcoded secrets, risky dependencies, and policy violations as code is written and committed.

For organizations where vibe coding is already happening across dozens of teams, that kind of continuous, automated governance is what keeps speed from becoming liability.

Final Thoughts on Protecting Your Codebase From AI-Generated Vulnerabilities

The shift to vibe coding brought real speed gains, but it introduced security gaps most teams aren't scanning for. AI models generate working code, not secure code, and the difference shows up in production as exposed admin endpoints and leaked DMs. You need continuous checks on AI-generated commits, not periodic audits that happen too late. Get started with Arnica to govern AI-assisted development before your team becomes the next Reddit case study.

FAQ

Can I build an AI coding app without writing security checks?

No. AI-generated code contains security vulnerabilities in 30-38% of cases based on published studies, meaning functional code from an LLM is not automatically secure code. You need to run static analysis, review authentication logic, and audit dependencies before production, regardless of how fast the AI writes.

Vibe coding security risks vs traditional coding vulnerabilities?

Vibe coding introduces vulnerability classes that traditional coding doesn't see at the same rate: hallucinated dependencies that don't exist until attackers create them, missing authorization checks that compilers don't flag, and prompt injection attacks that redirect the AI agent itself. Traditional code vulnerabilities come from human error; vibe coding vulnerabilities come from AI optimizing for working code instead of safe code.

What happened with the Tea app incident?

The Tea app exposed private user DMs to other users due to broken access control logic that AI generated without security review. The incident became a reference point in vibe coding security discussions on Reddit, where developers debate whether speed-to-ship culture is compatible with protecting user data.

How do hallucinated dependencies become security threats?

LLMs invent package names that don't exist in about 20% of AI-generated code samples. When models consistently hallucinate the same package names, attackers register those exact names and publish malicious code. Developers run the install command their AI wrote and pull attacker-controlled code directly into their project with no exploit required.

When should I treat AI-generated code as third-party code?

Every time. AI-generated code should be read, tested, and scanned before merge, just like unreviewed third-party libraries. The model has no awareness of your threat model, compliance requirements, or infrastructure context: it predicts what code should look like next, not what's secure for your environment.