Vibe Coding Security 2026: What New Research Means for Business

An app an AI agent put together in one evening can run flawlessly and still hand other people’s data to anyone who knows the API address. Two papers posted to arXiv this summer and autumn put a number on it for the first time: 182 of 200 publicly deployed vibe-coded apps had at least one vulnerability.

That is no reason to drop AI from development. It is a reason to understand where agents tend to slip, and what to verify before real customers, their data and their money touch the product.

91%

of audited apps had a vulnerability

182 of 200

65.8%

of the flaws were rated Critical or High

out of 1,186 confirmed

55.5%

came from protection nobody asked for

the most common cause

Why this matters right now

Vibe coding means describing what you want in plain language and letting an AI agent such as Claude Code, Lovable or Copilot write the code. The category is growing fast. According to Tech.eu, Lovable raised $400M at a $13.3B valuation in August 2026, and apps built on the platform draw more than 900M visits a month.

So this is no longer a developer side project. These are customer portals, booking tools and storefronts that real users rely on, and the first solid data on how safe they are has only just appeared.

Study 1: an audit of 200 live apps

Junquan Deng, Zhiyu Fan and Ruijie Meng gathered 9,041 open-source apps on GitHub in which an AI agent (Claude Code or Lovable) authored at least 90% of the code and commits. Of these, 984 had a public deployment, and 200 were picked at random for an in-depth audit. Two of the authors manually confirmed every finding.

The result: 1,186 confirmed vulnerabilities, about 6.5 per vulnerable app. 18.5% were Critical and 47.3% High. Slightly more than half sat in backend code rather than in the interface.

Mapped to OWASP, the widely used list of top web application risks, the spread looks like this:

• Broken access control 64 %
• Injection 54 %
• Authentication failures 51,5 %
• Cryptographic failures 36,5 %
• Security misconfiguration 36,5 %
• Vulnerable dependencies 28 %

Source: Deng, Fan, Meng, arXiv:2606.23130 (version of 14 Sep 2026)

In plain terms, the most frequent problem is that one user can view or edit another user’s records because the server never checks who owns them. Unsafe input handling and weak login come next. Broken access control also tops the current OWASP Top 10:2025, so the study fits the wider picture.

Why agents get it wrong

The most useful part of the paper is its root-cause analysis. The authors describe eight recurring failure modes; the main ones are below.

Cause	Share of flaws	What it looks like
Protection nobody requested	55.5%	The prompt never said “check permissions on the server”, so the agent didn’t
Demo-style design	14.7%	A static key or base64 “encryption” baked into the architecture
Change applied only partly	9.3%	A check added to new API endpoints but not to older ones
Side effect of a fix	8.4%	Security loosened to make a visible error go away
Security left to the user	6.1%	The agent says “remember to remove keys from the repo” and moves on
Forgotten obligations	4.2%	An “add password check later” note survives into production

Our takeaway: the issue is not that AI writes bad code. It does exactly what it was asked and stops there. Business owners ask for features (“build a customer dashboard”), not for security rules they may not know exist.

Study 2: asking for security helps

Darko Andročec of the University of Zagreb tested exactly that. Using Claude Code, he generated six web apps (a blog, a task API, a file upload service, a shop, a contact form with link previews and an admin dashboard) twice: once from a plain spec, once from the same spec with an OWASP-based security requirements section appended.

The plain versions had 51 confirmed findings; the security-aware ones had 24, and every one of the six apps improved. None of the security-aware versions had a Critical or High issue left. The author is upfront about the limits: a small corpus and a single generation per variant, so these are observations rather than a proven effect.

Two more points from this paper are directly practical:

• The worst flaw was caught only by hand. A login token was signed with a secret written into the code, so anyone could forge a session for any account. No automated scanner flagged it.
• Different methods catch different things. Only 12 of the 75 confirmed findings were spotted by more than one testing method. Trusting a single scanner gives a false sense of safety.

How the wording of the request changes the outcome

The first paper also measured this, across 1,680 runs. The agent was given tasks that had previously produced vulnerabilities, and the researchers tracked how often the flaw came back:

• Default request 25,7 %
• "Make it production-ready" request 11 %
• Agent with a security-hardening skill 11,9 %
• Detailed technical spec 45,7 %

Source: Deng, Fan, Meng, arXiv:2606.23130

The surprise is the last bar: a very detailed technical spec made things worse. The authors suggest the agent then follows the spec literally and skips any protection the spec leaves out. And in 20.7% of the affected runs, the agent noticed the risk itself but shipped the insecure code anyway.

Pre-launch checklist for an AI-built site

These are our recommendations, not any platform’s requirements. They apply to every project with logins, personal data, payments or an admin area.

1. State security requirements in the very first prompt. Server-side permission checks on every request, passwords stored only as hashes, secrets read from environment variables, form protection, upload limits. The second study suggests this alone noticeably reduces serious issues.
2. Test access as a different user. Create two test accounts and try to open, edit or delete one account’s data from the other by swapping the ID in the URL or request.
3. Hunt for keys in the code. Search the repository and the built frontend for strings like secret, key and token. Anything shipped to the browser is visible to every visitor.
4. On Supabase, check RLS. Supabase’s documentation says to enable Row Level Security on every table in an exposed schema; otherwise the data can be read and changed with the public key. The secret key that bypasses RLS must never reach the browser.
5. Turn off debug mode and detailed error messages on the live site.
6. Pair automation with manual review. A dependency scanner and static analysis are the baseline, but a person should verify the access logic by hand.
7. Re-check after every major change, not only before the first launch. Remember the “change applied only partly” row above.

When vibe coding is enough, and when it isn’t

In our view, the line is drawn by the cost of a mistake, not by the technology. A prototype, an internal tool with no personal data or a landing page without a backend: here vibe coding buys speed at little risk. A customer portal, payments, a CRM with a contact database or an admin panel: here you need someone who knows what must be protected and checks that it is.

If your product has outgrown the prototype stage and customers depend on it, the sensible next step is web application development with an architecture where permissions, secrets and checks are built in from day one, and AI stays a tool for moving faster.

What to do next

• If you already run a site or service built by an AI agent, work through the checklist above, starting with the two-account access test.
• Start new projects with security requirements in the prompt, not with “make it look nice”.
• Anything that handles money or personal data should get a manual audit before launch.

Want an outside look at your app? Tell us about your project and we will point out what to check first.

Author: Sergey Filatyev, founder of the Veb-Dev web studio.