Evidence
Other people have counted.
Security firms and academic researchers have gone and measured what happens to applications built the way yours was. Their findings are below, quoted as they were published, each with the name of whoever produced it, the date, and the sample it came from.
None of it is mine. What I can honestly say about my own work is the last section on this page, and it is short.
Apps like yours
These looked at apps that had shipped.
Each of these went and examined real applications, built on the platforms you are using, after they went live. That is as close as published research gets to your situation.
Deng, Fan & Meng
22 June 2026
“90% of deployed vibe-coded web applications are insecure with at least one vulnerability”
“76.7% of their vulnerabilities are classified as Critical or High severity”
“Broken Access Control, Cryptographic Failures, and Injection account for 74.4% of the vulnerabilities”
Understanding the (In)Security of Vibe-Coded Applications · arXiv:2606.23130Method
Searching GitHub for the fingerprints coding agents leave behind narrowed 74,800 candidates to 10,517 applications identified as vibe-coded, of which 1,170 were publicly deployed. Two hundred of those were sampled at random and audited, and each of the 1,471 confirmed vulnerabilities was reviewed independently by two of the authors, following OWASP risk-rating criteria.
This is a preprint, so it has not been through peer review, and the findings were confirmed by the authors themselves rather than by an outside party. Both are normal for work at this stage, and both are worth knowing before you lean on the number.
Symbiotic Security
2 June 2026
“98% of vibe coded applications have at least one security flaw”
We Scanned 1,072 Vibe Coded Apps, 98% Had Security FlawsMethod
Nineteen discovery sources found live apps by the fingerprints their platforms leave behind: Lovable, v0, Bolt, Replit, Windsurf and others, all on Supabase. An eighty-rule scanner then checked each one. 1,046 of the 1,072 sites carried at least one finding and 173 carried a critical one, for 6,185 vulnerabilities in total.
The scanner recorded that a vulnerability was present without exploiting it. These are findings, not confirmed breaches.
Escape
29 October 2025
“Our research team analyzed over 5,600 publicly available applications”
“identified more than 2,000 vulnerabilities, 400+ exposed secrets, and 175 instances of PII”
How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platformsMethod
Apps were found through the platforms’ own launch directories, Shodan and subdomain enumeration, then examined without logging in. The personal data included medical records, IBANs, phone numbers and email addresses. Educational and health domains were left out on ethical grounds.
Tenzai
13 January 2026
“Across all the applications we developed, we didn’t encounter a single exploitable SQLi or XSS vulnerability”
Bad Vibes: Comparing the Secure Coding Capabilities of Popular Coding AgentsMethod
The only controlled comparison here. Five coding agents each built three applications from identical prompts on the same stack during December 2025: Cursor, Claude Code, Codex, Replit and Devin. The fifteen results were then audited — 69 vulnerabilities, roughly 4.6 per application.
The textbook injection flaws were absent. What these agents left behind was almost entirely about who is allowed to do what.
A fifth study reports that one organisation in five building on these platforms is exposed. It is not on this page, because its publisher does not say how many applications the figure came from, and a number whose sample is unknown cannot be checked by you or by me.
The code underneath
It starts before the app exists.
These are not about deployed apps. They measure what language models produce when asked to write code, which is the raw material of everything above.
Perry et al.
November 2023
“participants who had access to an AI assistant wrote significantly less secure code than those without access to an assistant”
“Participants with access to an AI assistant were also more likely to believe they wrote secure code, suggesting that such tools may lead users to be overconfident about security flaws in their code”
Do Users Write More Insecure Code with AI Assistants? · Perry, Srivastava, Kumar and Boneh, Stanford · ACM CCS 2023Method
A study of people rather than a scan of code. Forty-seven participants were given five security-related programming tasks across three languages, two thirds of them with an assistant and the rest without, and both the code they produced and their confidence in it were measured. The effect held on four of the five tasks.
Forty-seven people is a small study, and it ran on the first generation of these assistants. It is here for what it measured rather than how many it measured: not whether the code was wrong, but whether the person believed it was right.
Veracode
28 July 2026
“roughly 44% of AI code generation tasks introduced a risky security vulnerability in tests”
“The average security pass rate across models is 56% – barely changed from 55% in the first report”
2026 GenAI Code Security ReportMethod
Eighty coding tasks spanning four languages and four weakness classes, run against more than 150 models. Veracode has kept the same benchmark since 2025 and re-run it, which is what makes the second sentence worth reading: syntax correctness now exceeds 95%, so the code compiles and runs. The security rate is the part that has not moved.
GitGuardian
17 March 2026
“28.65 million new hardcoded secrets were added to public GitHub commits in 2025 alone, a 34% increase year over year and the largest single-year jump we’ve recorded”
The State of Secrets Sprawl 2026Method
Drawn from about 1.94 billion public GitHub commits made during 2025. A secret here is a working credential, committed somewhere anybody can read it: an API key, a token, a database password.
None of this is new. In August 2021, Pearce and colleagues examined 1,689 programs written with the first widely used code assistant and reported “approximately 40% to be vulnerable”. The tools have improved enormously in the years since. The distance between what they write and what is safe to put in front of users has not closed. Asleep at the Keyboard?, arXiv:2108.09293
What has happened
When nobody checks the default.
Both of these were found by researchers, reported, and fixed. They are here for their shape rather than their frequency: a setting nobody revisited, and a stretch of time in which anybody who looked could read what was behind it.
CVE-2025-48757
Disclosed 29 May 2025
Row-level security missing on live apps
Matt Palmer found apps generated on Lovable reaching production with row-level security absent from their database tables. His follow-up scan reported “303 endpoints across 170 projects”, roughly 10.3% of the 1,645 projects he analysed, readable without logging in: email addresses, phone numbers, payment and subscription status, API keys. He notified Lovable on 21 March 2025, a patch followed on 24 April, and the CVE was published on 29 May.
The CVE record carries Lovable’s rebuttal, that “each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application”. Their position is a fair one, and it is also the argument of this entire site: the platform builds the app, and the rules protecting what is inside it stay yours. Palmer works at Replit, a competing platform, which is worth knowing when you read him.
Broken access control
Disclosed 20 April 2026
Object-level authorisation left open for 48 days
A flaw in Lovable’s API let one account read another account’s data, and the same leak exposed hardcoded Supabase credentials. It reached the bug bounty programme on 3 March 2026 and became public on 20 April. Lovable patched it for new projects rather than existing ones, so every project created before November 2025 carried it until its owner did something. The Next Web reported that “the vulnerability had been open for 48 days”.
Neither is an argument against the platform that carried it, and both were reported through the proper channel and patched. They belong here because a patch reaches the platform long before it reaches your app, and in the second case it never reached the projects that already existed at all.
What I have not measured
I have no numbers of my own.
I have not read enough apps to publish a count, and inventing one on a page like this would undo everything else on it.
When that changes it will be a single number carrying a date, stated the same way these are, and it will be a small number at first. You will be able to tell it apart from the ones above because it will be the only one on this page with my name on it.
What I will say without a number: AI-built apps tend to share the same five weaknesses. Hardcoded keys, row-level security left switched off, missing input validation, broken authentication logic, and data leaking through the console. Every audit names all five and reports what it found for each. How often any one of them turns up across everybody’s apps is not something I can tell you yet.
Your app
None of this tells you about your app.
Prevalence is somebody else’s measurement, and it says nothing about the code you shipped. A fixed-scope read of your own app does. Five questions first, and a straight answer about whether it is worth your money.