TLDR: We analyzed 50 vibe-coded projects and found that 86% contained security vulnerabilities, ranging from insufficient input validation to remote code execution and exposure of personal user information.

This blog can also be read on our website

What even is vibe coding?

There are many Ai assistants such as Cursor or Windsurf to this date which help you write code for you. Programmers no longer need the technical expertise to create an MVP of an app. Creating applications or websites without having the knowledge of what you are doing is often referred to as “vibe coding”.

What is this article about?

In this article, we will have a look at how vibe coding impacts code security, the implications it already has, and how we can prevent such critical bugs from happening?

The problem with vibe coding

We have analyzed 50 projects’ source code or production API which likely were made using Ai toos, ranging from simple projects like note taking applications to more complex applications with thousands of users. Of these projects, 43 were vulnerable to attacks, reaching from a simple enumeration exploits to full remote code execution.

All vulnerabilities found were disclosed and fixed by the developer(s).

We have compiled a table from that data which highlights the vulnerability type and the number of projects which were affected. Our table therefore does not sum up to 50, but instead the total number of vulnerabilities found during our analysis.

Vulnerability Type	Vulnerability Count
Full user access with PII	2
Remote Code Execution	3
Unintentional CORS *	4
Dependencies with known vulnerability	9
Enumeration attacks	24
XSS attacks	27
CSRF attacks	28
Insufficient input validation	41

With help from this table, it is notable taht most of the attacks were caused by the lack of input validation, which can be prevented with proper input validation. AIs make this mistake because they do not plan ahead what they are doing, and neither are they taught to reason about their code’s security, nor about it’s quality. The API routes often elicited an error message to the attacker with sensitive information, such as, but not limited to paths, filesnames and sometimes values from the database or stack used in the application. Here is an example of vulnerable code and how it could have been fixed:

Old code

async createSet(data: Prisma.SetCreateInput, userId: string) {
return this.prisma.set.create({
data: {
...data,
author: {
connect: {
id: userId,
},
},
},
});
}

Fixed Code

async createSet(data: CreateSetDTO, userId: string) {
return this.prisma.set.create({
data: {
name: data.name,
description: data.description,
author: {
connect: {
id: userId,
},
},
pairs: {
createMany: {
data: data.pairs.map(pair => ({ key: pair.key, value: pair.value }))
}
},
},
});
}

As you can see, it is not hard to catch such vulnerabilities and fix them.

The second most found vulnerabilities are CSRF and XSS attacks.

XSS attacks happen when the user loads malicious content, e.g. content from another user that executes code. This can be prevented with proper input validation. Most modern frameworks also handle that for you.

CSRF attacks occur when an attacker tricks the victim into submitting a malicious request to a web application, where the browser authenticates the request with cookies. This can easily prevented by using proper CSRF tokens. The easiest way to prevent CSRF attacks is to not use cookies and rather manually set bearer tokens in the header of each request to the backend.

Enumeration attacks were also quite common. This vulnerability is used in combination with other vulnerabilities to quickly download data, that otherwise would have required large amounts of time to discover. One simple way of preventing enumeration attacks is using non-incremental IDs in your database. Implementing something safer, like UUIDs will make it harder (if not almost impossible) to guess the IDs.

Quickly disregarded by unexperienced developers were outdated dependencies, which had known vulnerabilities, that simply could have been prevented, by updating the dependencies of the project to the latest version. While this is not an issue of vibe coding itself, vibe-coders don’t know the importance of chores.

CORS attacks were also found in a few projects. This is likely just a leftover from development but cannot happen. We think that the source of such vulnerabilities are likely a “fix” by some Ai tool, which was never removed because the developer(s) were not aware of its existence.

Now to the more interesting vulnerabilities. The first we found was a vulnerability to execute code on the backend. Each of the 3 times we found a remote code execution vulnerability, the backend code was running another binary without proper input validation. This leads back to the first attack with insufficient input validation, which can be prevented by using proper input validation or even better not needing to run external binaries in the first place.

As already mentioned, the last vulnerability is related to the vulnerability with the enumeration attack. This vulnerability allowed anyone to request data about a user, including personal information such as email addresses, phone numbers, github and google access tokens, full names and more.

A lot had gone wrong there. The backend code had no implementation of access controls and data shadowing was therefore sending any user data to the client. Based on the response, we can tell that absolutely no testing was made because that would have easily been seen by the developers.

This likely happened because the AI tool generated code that selected the whole user and did not remove the password and other fields from the response.

We have tested our theory a few times on our own and have come to the conclusion that Ai fails to implement permission checks and often selects too much data, because it is not aware of the context.

What can we learn from this?

Ai is a great tool for creating content quickly, but it can also be a great path to createing critical security vulnerabilities and bugs.

We think that it is important that you understand your own code, or the one of your AI assistants. Always have a second look at your code and make sure that you understand what it is doing.

If you have got your own application or website, you can contact us and we will be happy to help you with finding bugs and vulnerabilities.

With love from Switzerland 🇨🇭

• Epilogue Team
• contact@epilogue.team