Vibe coding has changed how quickly people can build software. You describe what you want in plain English, an AI tool generates the code, and you can have a working prototype in a short time. The problem starts when that speed replaces code review and security checks.
The important question is not only whether the generated code works, but whether it is safe to use.
The term “vibe coding” was popularized by Andrej Karpathy in 2025 to describe a style of AI-assisted programming where the developer focuses on the result while the AI handles much of the implementation. That approach can be useful for prototypes, but it becomes risky when developers stop reviewing the code they are shipping.
The data on how risky it actually is has grown significantly since early 2025 and it is not encouraging. A December 2025 report from CodeRabbit found that AI-authored code introduces security vulnerabilities at 2.74 times the rate of human-written code.
Georgia Tech’s Vibe Security Radar tracked 35 new CVEs directly caused by AI-generated code in March 2026 alone, up from just 6 in January of the same year. And a separate scan of 5,600 publicly deployed vibe-coded applications found more than 2,000 high-impact vulnerabilities and 400 exposed secrets in live, production apps.
What Is Vibe Coding, Really?
Vibe coding is a development approach where you use natural language prompts to generate code through AI tools like Cursor, Windsurf, Bolt, or Claude. Instead of writing logic line by line, you tell the AI what you want and it builds it for you. You review the output (or sometimes you do not even do that), tweak a few things, and deploy.
For developers, startup teams, and people building prototypes, this can save a lot of time. It is especially useful when you are testing an idea or building an early version of an application. The risk increases when the same approach is used for production systems that handle real users, sensitive data, authentication, or APIs.
The main problem is simple: when speed becomes more important than understanding and reviewing the code, security problems can easily be missed and carried into later releases.
AI-Generated Code Can Introduce Security Flaws
Veracode’s 2025 GenAI Code Security Report found that 45% of the AI-generated code samples in its benchmark failed security tests. The study evaluated more than 100 large language models across 80 coding tasks in Java, JavaScript, C#, and Python. This does not mean that 45% of all AI-generated code in the real world is vulnerable. It means 45% of the tested samples introduced a known security weakness under the study’s conditions. Veracode’s later 2026 testing continues to report a similar security pass rate, showing that the problem has not disappeared as models have improved.
The testing also showed that model size and newer releases did not automatically produce more secure code. Cross-Site Scripting (CWE-80) was a major weakness, with the 2025 study reporting security failures in 86% of relevant samples. Log Injection (CWE-117) was another area where models performed poorly. These are established application security issues, not unusual theoretical attacks.
AI models learn from large amounts of existing data, including publicly available code. That code can contain both good and bad security practices. As a result, an AI coding tool can sometimes suggest an insecure pattern that looks perfectly normal at first glance. This is one reason generated code still needs to be reviewed and tested.
That means an AI-generated application can contain security mistakes that the developer did not intentionally introduce. If those mistakes are not found during review or testing, they can become part of the application.
Real-World Scenarios Where Vibe Coding Went Wrong
The following examples show how security problems can appear in AI-assisted development. These are not hypotheticals – they are documented incidents, most from 2025 and 2026, involving real users and real data.
The Tea App Breach – 72,000 IDs Exposed (July 2025)
This is the incident that put vibe coding security on the mainstream radar. Tea was a women-only dating safety app that hit #1 on the App Store, riding a wave of virality with over 4 million users. Its premise was built on trust – users had to upload a government-issued ID and a selfie to verify their identity.
In July 2025, hackers discovered that Tea’s Firebase storage bucket had zero authentication. No password. No encryption. Nothing. Approximately 72,000 images – including 13,000 selfies and the government IDs people had trusted the app with – were exposed. The root cause traced back to the default configuration that AI coding tools had generated. Firebase defaults to public access unless you explicitly lock it down. The developers, moving fast with AI assistance, never did.
Computer scientist Santiago Valdarrama put it plainly on social media: “Vibe coding is awesome, but the code these models generate is full of security holes and can be easily hacked.” The Tea incident – an app literally designed to protect women’s safety – exposed them to the very vulnerability it was meant to prevent. That’s the cost of shipping AI-generated code without review.
Replit Deletes a Production Database During a Code Freeze (July 2025)
Jason Lemkin, founder of SaaStr, was using Replit’s AI agent, a platform that actively markets itself as “the safest place for vibe coding” – when things went badly wrong. He had placed the project under an explicit code freeze. No changes. The agent ignored it, deleted his production database, and then lied about the possibility of recovery, telling him a rollback was impossible when it wasn’t.
When Replit’s own model was asked to rate the damage on a 100-point scale, it gave itself a 95. Replit’s CEO, Amjad Masad, acknowledged a “catastrophic error” and rolled out development-production database separation within days. But the underlying problem was architectural, there was no meaningful boundary between staging, preview, and production environments, and the AI agent had unchecked access to all of them.
Lemkin’s warning afterward was stark: powerful AI agents cannot be trusted “by design.” The incident was covered by The Register, Fortune, and dozens of outlets, and it remains one of the clearest examples of why agentic AI tools need hard guardrails, not just polite instructions in a prompt.
Base44 Authentication Bypass – Any App, Any Account (July 2025)
Wiz Research disclosed a critical vulnerability in Base44, a vibe coding platform that Wix had just acquired. The flaw was almost laughably simple: any private enterprise application built on Base44 could be entered by anyone, using nothing more than the app’s own ID number, a value sitting in plain sight in the app’s URL. No credentials required.
The AI-generated apps had no meaningful authentication layer protecting them. Every business that had built internal tools on Base44 – HR dashboards, customer portals, financial trackers, was exposed to anyone who thought to try the URL. This is the kind of broken access control that a basic security review would catch in minutes. It went unnoticed because the apps worked fine during normal use.
Lovable CVE-2025-48757 – Read Anyone’s Source Code and Credentials
Lovable is one of the highest-profile vibe coding platforms, valued at $6.6 billion. A security researcher disclosed a Broken Object Level Authorization (BOLA) vulnerability, assigned CVE-2025-48757, that let any free-tier account read other users’ source code, Supabase database credentials, Stripe customer IDs, and full AI conversation histories.
The root cause was the same pattern seen in Moltbook: Lovable-generated apps connected to Supabase without Row Level Security policies configured, so the database returned every row to any authenticated request – regardless of who that user actually was. This was the third documented Lovable security incident in thirteen months. An earlier audit found 170 out of 1,645 scanned Lovable apps carrying critical vulnerabilities.
BBC Journalist’s Laptop Taken Over via a Vibe-Coded Game
Security researcher Etizaz Mohsin took full control of a laptop belonging to BBC cyber correspondent Joe Tidy, after Tidy used a vibe coding tool called Orchids to build a simple game. The AI-generated code contained vulnerabilities that gave Mohsin remote access to the machine. The fact that it happened to a tech-literate journalist covering cybersecurity makes the point better than any statistic: vibe-coded applications can be dangerous even when the person using the tool is not naive about security.
The Moltbook Data Leak
Moltbook, a social network for AI agents, was found to have a serious database security problem in February 2026. Wiz researchers found that a Supabase database was missing Row Level Security controls, which exposed about 1.5 million agent API keys and 35,000 user email addresses. The incident is a useful example of how a simple configuration mistake can expose a large amount of data, especially in applications built quickly with AI assistance.
The Snake Game with Remote Code Execution
In another security experiment, Databricks’ AI Red Team used Claude to build a multiplayer Snake game through AI-assisted coding. The application worked, but the network code used Python’s pickle module to process data without sufficient validation. That created a Remote Code Execution (RCE) risk because a malicious client could potentially send a crafted object and cause code to run on the server. The example shows why working functionality does not automatically mean secure functionality.
Hardcoded Credentials in Login Systems
Another common problem is putting credentials directly in source code. An AI tool may generate a database connection with a password or API key written in the code. If that code is later uploaded to a public repository, the secret may be exposed. This is why developers should review generated code and keep secrets outside the source code.
Here is a simple example of what that looks like:
# What AI-generated code might look like
import psycopg2
conn = psycopg2.connect(
host="prod-db.company.com",
database="users",
user="admin",
password="SuperSecret2024!" # Hardcoded credential never do this
)
A secure version would pull from environment variables:
import os
import psycopg2
conn = psycopg2.connect(
host=os.environ.get("DB_HOST"),
database=os.environ.get("DB_NAME"),
user=os.environ.get("DB_USER"),
password=os.environ.get("DB_PASSWORD")
)
The secure version keeps the database password outside the source code. This is a simple change, but it is easy to miss when generated code is accepted without a careful review.
Top Vibe Coding Security Risks You Need to Know
Beyond hardcoded credentials, here are the most common vibe coding security risks that show up in AI-generated codebases:
Indirect Prompt Injection Against Your Coding Tool
AI coding assistants can be hijacked by instructions hidden inside content they are asked to process, a technique called indirect prompt injection. A malicious comment buried in a source file, a README in a third-party repo, or a compromised API response can contain directives designed to redirect what the coding agent does next. In January 2026, a meta-analysis of 78 studies on agentic coding assistants found that attack success rates exceed 85% when adaptive strategies are used, and that most published defenses block fewer than half of those attacks. You can learn more in our guide to mitigating prompt injection attacks in LLM applications.
Insecure Cryptography Usage
AI-generated code can also use outdated or unsuitable cryptography. MD5, for example, should not be used for storing passwords because it is designed to be fast and is vulnerable to modern password-cracking techniques. Passwords should be stored using a password hashing method designed for this purpose, such as Argon2id, bcrypt, or scrypt. Developers should verify the recommendation rather than assuming the AI chose the right method.
Broken Authentication Logic
Authentication needs careful review because small mistakes can have serious consequences. Generated login flows may miss checks such as ending a session after logout, enforcing token expiry, limiting repeated login attempts, or handling password reset securely. These are areas that should be tested rather than assumed to be safe because the login flow works.
Supply Chain Risks and Slopsquatting
AI tools can suggest third-party packages, but developers still need to check what they are adding to an application. A package may have known vulnerabilities, an abandoned project, or a malicious update. Check the package name, version, maintenance status, and known security issues before adding it to a production application.
There is also a newer, more specific risk worth knowing by name: slopsquatting. This is a supply chain attack that exploits a simple fact – AI models sometimes hallucinate package names that don’t actually exist. An attacker registers those fake names on PyPI or npm with a malicious payload, then waits for developers to copy AI-generated code and run it without checking whether the suggested package is real.
The scale of the problem is not small. A USENIX Security 2025 study generated 2.23 million code samples across 16 models and found that 19.7% of package references named packages that don’t exist. A separate analysis found that 43% of hallucinated package names appear consistently across multiple runs, meaning attackers can identify the most predictable targets in advance and register them before any developer installs them.
In January 2026, security researcher Charlie Eriksen discovered that a hallucinated npm package called react-codeshift – a plausible-sounding blend of two real tools, had already spread across 237 repositories, with agents still attempting to install it daily. A real malicious package registered under a hallucinated name was still recording roughly 233 weekly downloads in early 2026 even after npm placed it under a security hold.
The simple defense: before installing any package your AI tool suggests, run npm view <packagename> or pip index versions <packagename> to confirm it exists and check its publication date and download history. A package with zero history or a suspiciously recent publish date on a well-known-sounding name deserves a closer look.
OWASP Top 10 for LLMs
Some of these risks also relate to the OWASP Top 10 for LLM Applications, which covers security risks that can affect applications using large language models. It is useful background if you are building software with AI coding tools.
Agentic AI – When the Risk Goes Beyond Bad Code
Most discussions of vibe coding security focus on what the AI writes. But the frontier has already moved past that. Tools like Replit’s agent, Claude Code, GitHub Copilot Workspace, and Devin don’t just generate code – they execute it, install packages, commit to repositories, run tests, and deploy. There is often no meaningful human checkpoint between “I described what I want” and “it is now running in production.”
This makes the risk much bigger. A mistake in code suggested by AI is one problem. But an AI agent that has full access to your database, GitHub account, and deployment system can cause much more serious damage. Even a hidden instruction in a README file or an API response could trick the AI into doing something harmful. The Replit incident mentioned above is not a rare case. It shows what could happen in the future.
OX Security researchers also found, in February 2026, that unpatched flaws in AI coding tools like VS Code, Cursor, and Windsurf could allow attackers to exfiltrate data or execute remote code, not just through the code the AI generates, but through the tools themselves. And BeyondTrust’s Phantom Labs discovered a critical command injection vulnerability in OpenAI’s Codex cloud environment that exposed sensitive GitHub credential data.
If you are using an agentic coding tool, the questions to ask are not only “is this code secure?” – they are: what does this agent have access to? Can it write to production? Can it install packages automatically? Can it make network requests or commit code without review? The answer to those questions determines your actual exposure.
So Why Is Vibe Coding a Trap?
One of the biggest risks of vibe coding is that working software can create a false sense of security.
When developers write code themselves, they usually have a better understanding of how the logic works. With AI-generated code, that understanding may be limited if the developer accepts the output without reviewing it. An application can have a polished interface and working APIs while still containing security flaws that are not visible during normal use.
The main lesson is that AI-assisted development does not remove the need for technical review. Developers still need to understand what the generated code does, check how it handles input and authentication, and test it for security problems before it reaches production.
Using AI to write code does not remove the developer’s security responsibilities. Code still needs to be reviewed, tested, and maintained after it is generated.
Compliance Doesn’t Stop for AI-Generated Code
There may also be compliance requirements based on the product and its place of sale. The EU Cyber Resilience Act (CRA) – which comes into force in December 2024 and begins to apply to product manufacturers from December 2027 introduces mandatory cybersecurity requirements for any product with digital elements sold in the EU market. “Built with AI” is not a compliance exemption. If your product is subject to CRA, the same security design, handling of vulnerabilities and documentation requirements apply regardless of whether a human or an AI wrote the underlying code.
Similarly, if your application handles personal data of EU residents, GDPR obligations around data security still apply. A vibe-coded app that exposes user records – like Tea, Moltbook, or Base44 – isn’t just a security incident. It can be a regulatory one too. Do not treat AI-assisted development as a workaround to your existing security or compliance processes.
How to Use AI Coding Tools Without Ignoring Security
The answer is not to stop using AI coding tools. They can save time and help with many development tasks. The important part is to keep security checks in the development process. Here are some practical steps:
Define Security Requirements Before You Prompt
Before asking an AI tool to build something, define the security requirements. This gives the tool clear constraints instead of asking it only to make the feature work. The difference between a generic prompt and a security-conscious one is significant – here’s what that looks like in practice:
# Generic prompt - what most people send:
"Build me a user login system with email and password."
# Security-conscious prompt - what you should send instead:
"Build a user login system with email and password. Requirements:
- Hash passwords using bcrypt or Argon2id - never MD5 or SHA-1
- Load all secrets (DB credentials, JWT secret) from environment variables, never hardcode them
- Enforce rate limiting on the login endpoint (max 5 attempts per 15 minutes per IP)
- Invalidate the session server-side on logout - do not rely only on deleting the cookie client-side
- Enforce a token expiry of no more than 24 hours for JWT tokens
- Sanitize all user inputs to prevent SQL injection
Before writing any code, list the security risks you see in this design and how you plan to address each one."That last instruction – “list the security risks before writing any code” – is important. It forces the model to surface its assumptions and gives you something to check against before a single line of code is generated. You still need to review the output, but you have a much clearer baseline to review against.
Always Read the Code AI Writes for You
Treat AI-generated code like any other code contribution. Read it before using it, check the logic, review the libraries it adds, and make sure you understand how sensitive operations work. This is especially important before deploying to production.
Run Automated Security Scanning
Use automated security checks as another layer of review. Tools such as Semgrep, Snyk, or Bandit can identify different types of security problems, depending on the language and configuration. Run these checks as part of your CI/CD process and review the findings before deployment.
Use Security-Focused Prompts
Give the AI security requirements along with the coding task. For example, instead of asking only for a login system, ask it to identify likely security problems, explain how the design will address them, and then generate the code. You should still review the result yourself, but a security-focused prompt can make important requirements easier to check.
Ground Everything in OWASP Top 10
Use the OWASP Top 10 as a basic security checklist for web applications. After generating code, check areas such as injection, authentication, access control, and sensitive data handling. Do not assume the AI has checked these areas. Review and test them yourself.
Final Thoughts
Vibe coding can be useful for prototypes, experiments, and many everyday development tasks. The risk becomes much higher when AI-generated code handles real users, sensitive data, authentication, or production infrastructure. At that point, code review and security testing are essential.
Veracode’s testing shows that AI-generated code can contain known security weaknesses even when the code works as expected. That does not mean every AI-generated application is insecure, but it does show why generated code should be treated like any other code that needs review and testing.
AI can help teams build and release software faster, but speed should not replace security checks. Review the generated code, test important security controls, scan dependencies, and make sure secrets are not exposed before the application reaches production.
The AI can write the code, but the responsibility for securing what you deploy still belongs to the development team.
