Introduction: vibe coding meets cybersecurity

The vibe coding is radically transforming the way applications are developed. Thanks to AI assistants and LLMs, it is now possible to generate a complete application – frontend, backend and API – simply by describing the functional intent. This approach means that prototypes can be produced in a matter of hours instead of weeks.

The product :

The application tested was 100% vibe coded with Claude’s Opus 4.6. It took the developer two weeks to generate a finished product that was both ergonomic and aesthetically pleasing. The developer had even asked Claude to carry out a pentest, which had already revealed a number of more or less critical flaws.

But a key question arises for cybersecurity teams: what happens when these AI-generated applications go into production without a security audit?

To answer this question, we carried out a pentest of an entire web application, in a grey-box context, with standard user access.

The results are instructive and several critical vulnerabilities were identified on the first day, including :

• Local File Inclusion (LFI)
• IDOR (Insecure Direct Object Reference)
• vulnerable dependencies
• unsecured upload function
• Potential SSRF

These vulnerabilities illustrate a key point: AI-generated code is often perfectly functional, but rarely secure by default.

In this article, we analyze the main vulnerabilities discovered and the lessons to be learned for CISOs and DevSecOps teams.

Pentest methodology

The security test was carried out in a“grey-box web application pentest” context.

This means that :

• the application was accessible via the Internet
• test user accounts were provided
• the source code was not initially accessible

The aim was to reproduce the behavior of an external attacker.

The methodology used is based on :

• OWASP Top 10
• automated testing
• manual analysis
• HTTP parameter fuzzing
• API endpoint analysis

Tools used :

• Burp Suite
• Nuclei
• advanced manual testing

This approach makes it possible to identify both :

• technical vulnerabilities
• business logic problems.

Critical vulnerability: Local File Inclusion (LFI)

The most critical vulnerability discovered during the pentest is a Local File Inclusion (LFI).

This vulnerability allows an attacker to access sensitive files on the server.

In the application analyzed, a user-controlled parameter was used directly to load files onto the system.

Here is the equivalent vulnerable code:

The “full_path” parameter was not correctly filtered, so an attacker could use a“path traversal” attack. For example:

../../../../etc/passwd

This request accesses the system file /etc/passwd, as shown below:

Impact of the LFI

A BIA can :

• access to configuration files
• exposure of environmental variables
• credential recovery
• access to source code
• preparation for subsequent attacks

In some cases (unfortunately not here, as the necessary files have not been identified), a LFI can even lead to Remote Code Execution (RCE).

This vulnerability belongs to OWASP category A02 – Security Misconfiguration.

Vulnerable addictions: the invisible problem

Another problem identified concerns the dependencies used by the application.

The frontend used the Vite library version 5.4.10. This version contains several known vulnerabilities:

• CVE-2025-31125
• CVE-2025-30208
• CVE-2024-23331

As with the LFI described above, these vulnerabilities potentially allow unauthorized access to system files. This problem is very common in AI-generated projects.

Why?

Because :

• automatically select dependencies
• do not include safety monitoring
• do not check for vulnerable versions

As a result, the application may contain known vulnerabilities as soon as it goes into production.

IDOR: access to other users’ data

Another important vulnerability identified during the pentest was an IDOR (Insecure Direct Object Reference).

In the application, user profiles were accessible via an identifier in the URL.

Example:

/employee/{user_guid}

Since GUIDs are unique identifiers, they’re impossible to guess. So we need to find a way for the application to give them to us directly. After a tour of the various API calls, we identified “/api/leaderboard”, which returns the GUIDs of all employees:

By modifying this GUID with one of the GUIDs obtained, for example that of the tech lead, it was possible to access the data of other users:

Exposed data

API endpoints returned :

• email
• user role
• internal identifiers
• password hash (unfortunately unused, as the application uses OAuth tokens)

Impact

This type of vulnerability can :

• leakage of personal data
• preparation of targeted attacks
• privilege escalation

This vulnerability corresponds to OWASP A01 – Broken Access Control.

Other vulnerabilities observed

The pentest also revealed several additional vulnerabilities:

• potential SSRF blind
• software version disclosure
• missing HTTP security headers
• weak password policy
• environment staging exposed
• No antivirus on file upload function

Individually, these vulnerabilities are often classified as low or medium criticality. But combined, they can facilitate more advanced attacks.

Why vibe coding generates these vulnerabilities

The pentest revealed several structural weaknesses in vibe coding.

1. Despite AI code review, it still can’t see everything

AI-generated applications rarely go through a human safety review.

2. Insufficient user input validation

AI models focus on functionality rather than safety.

3. Incomplete access controls

Authorization rules are often forgotten or poorly implemented.

4. Unsecured dependencies

The library versions used are not verified.

How to secure a coded vibe application

Organizations adopting vibe coding need to adapt their security practices.

Here are a few recommendations.

Integrating safety into the pipeline

• SAST
• DAST

Scanning dependencies

• OWASP Dependency Check
• Snyk
• Dependabot

Applying the principle of least privilege

Each endpoint must verify :

• authentication
• authorization

Create regular slopes

Vibe coding accelerates development.

But it also accelerates the spread of vulnerabilities.

Conclusion

Vibe coding opens up a new era in software development.

But our pentest shows that AI-generated applications still often present :

• critical vulnerabilities
• vulnerable dependencies
• inadequate access controls

For CISOs and CISOs, the conclusion is simple: an AI-generated application must be audited like any other mission-critical application.

Otherwise, AI risks accelerating not only innovation… but also attacks.

Are you developing applications with AI or vibe coding?

Our teams carry out specialized pentests on AI-generated applications to identify vulnerabilities before they are exploited.

Contact us for a security audit or an advanced application pentest.