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.
Security testing also shows why this needs attention.
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.
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:
Prompt Injection Through Dependencies
AI coding assistants can also be affected by instructions hidden inside content they are asked to process. For example, a malicious comment in a source file could contain instructions intended to influence the coding assistant. This is related to prompt injection, where untrusted content attempts to change how an AI system behaves. 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
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.
OWASP LLM Top 10 Violations
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.
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.
The main point is simple: 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.
There can also be compliance requirements depending on the product and where it is sold. For example, the EU Cyber Resilience Act introduces cybersecurity requirements for products with digital elements. If AI-generated code is used in a product covered by such rules, normal security review and development controls still apply. Do not treat AI-assisted development as an exception to your security or compliance process.
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. For example, tell it not to hardcode secrets, validate user input, protect database access, and apply rate limits to login endpoints. This gives the tool clear security requirements instead of asking it only to make the feature work.
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.
References and Further Reading:
Veracode 2025 GenAI Code Security Report
Kaspersky: Security Risks of Vibe Coding and LLM Assistants (2025)
