Vibe-coding is increasing. Vibe-coded apps tend to be buggy. Is this a worrying sign for the future?
Vibe coding, the use of AI to assist or perform code generation, is increasing dramatically. In May 2026, Hostinger reported, “90% of developers regularly use at least one AI tool at work as of January 2026.” This is likely to increase through the basic business pressure that applies to everything: we need more, faster and cheaper.
But while vibe coding is increasing in volume, so are concerns over the security of vibe-developed apps.
Xint.io, the web platform that delivers Theori’s AI driven autonomous pentest code (Xint), decided to analyze vibe-coded apps to quantify what, where, why and how often vibe coding introduces security weaknesses into the apps it touches.
To achieve this, Xint created three tests reflecting the most common AI-assisted development workflows:
- on a new app from a well-written spec (greenfield, as with an experienced developer overseeing the process)
- on a new app representing the growing incidence of the casual coder saying, ‘just build this’ (greenfield)
- on a hardened app (Gnuboard7) to see if hardening introduced new vulnerabilities (the brownfield comparison).
Although Gnuboard7 (a legacy PHP app) is an established app, Xint needed to examine it as if it were an AI-assisted app. So, they migrated it into a Laravel + React architecture “and asked AI to harden it.” The migration created a contemporary baseline so the vulnerabilities found would reflect AI reasoning limits, not legacy quirks.
Each app was given a 30-minute scan for runtime and source code analysis by Xint. It found a total of 434 exploitable security issues: 196 in the greenfield apps, and 238 in the single brownfield app.
The primary conclusions reached by Xint.io cover four areas: the most common flaws in AI code; the most common severe flaws; the effect of the app size on the flaws introduced; and has AI made any advances in producing secure code?
Missing controls for rate limiting and DOS are the most common flaws. Resource exhaustion/DOS accounted for 93 of the 434 flaws. Authorization and insecure direct object reference, where users get access to data beyond their permissions, came second with 88 flaws; and access boundary/traversal/SSRF flaws were third with 54.
Such flaws occur when the developer only asks for features. “The impact is not data theft, but in real operation it means runaway server cost or a server an attacker can knock over,” warns the report.
Xint’s advice: “Don’t just check to see if AI code compiles; look for how it performs and the resources it consumes in runtime.”
Secrets exposure is the top source of critical-severity flaws. There were 23 critical findings, with hardcoded or default secrets the most common at 11. Debug-mode RCE accounted for another six.
“Look for hardcoded secrets, such as API keys or PII, embedded in code produced by AI,” advises Xint.
Size matters. “Fine-grained authorization holds up on small apps but breaks as the app grows,” warns the report. While IDOR flaws comprised just 11% of the flaws in the smaller greenfield apps, they comprised 28% in the larger brownfield Gnuboard7 app.
“Double check granular object permissions as the amount of endpoints in an application increases,” suggests Xint.
Despite these continuing flaws being introduced by vibe coding, Xint’s fourth conclusion is that vibe coding AI is improving. Before starting the analysis, Xint had expected to find a large number of injection flaws (SQLi, XSS) and IDOR/BOLA-style access-control bugs. It found the opposite. Injection barely showed up, while IDOR/BOLA flaws were far less common than expected.
“This suggests the foundational labs have genuinely improved in these areas,” comments the report.
The purpose of the Xint study was not to demonstrate that vibe coding introduces bugs (that was already known), nor to stop companies using vibe coding (that isn’t going to happen). However, knowing the most common flaws and understanding how and why they occur can help developers overcome them – either by including prompts that eliminate the flaws and/or checking for their existence after generation.
By understanding the weaknesses in vibe coding, developers can play to its strengths in the future.
Related: Everybody Is Vibe Coding But Nobody Told the Security Team
Related: Backslash Raises $19 Million to Secure Vibe Coding
Related: Vibe Coding Tested: AI Agents Nail SQLi but Fail Miserably on Security Controls
Related: Vibe Coding: When Everyone’s a Developer, Who Secures the Code?
