The State of Vibe-Code Security
Every published figure we could verify on how often AI-built ("vibe-coded") applications ship with security flaws, set side by side with its sample size, publication date, method and scope. The comparison is the contribution. Not one number on this page was collected, altered or re-derived by us.
The headline numbers, each with the study that published it.
Every figure above is linked to its original publisher in Methodology and sources. Rescue Engineers has not altered or re-derived any number. We hold no proprietary dataset and have published none. These figures measure different things over different populations, so before quoting any two of them together, read what compares.
Which of these numbers can actually be compared?
These figures get quoted interchangeably, and almost none of them measure the same thing. The table below puts all nine sources side by side with what each number counts, the population it covers, its sample size and its method, grouped by measurement class. Two figures in the same group can be discussed together with care. Two figures in different groups cannot be compared at all.
| Source and date | Headline figure | What that number counts | Population it covers | Sample | Method |
|---|---|---|---|---|---|
| Group A · Live deployed apps, probed from the outside | |||||
| Escape 29 October 2025 |
2,000+ vulnerabilities, 400+ exposed secrets, 175 instances of exposed personal data | A raw count of findings. Not a share of apps, and it does not divide by the sample to give a per-app rate. | Publicly reachable apps on Lovable, Create.xyz, Base44, Bolt.new and Vibe Studio. | 5,600 apps | Passive scanning only, no destructive payloads. The authors call it "a conservative baseline". Education and health domains excluded. |
| ModernPentest 26 January 2026 |
28% leaking personal data. 20.1 million rows reachable anonymously. 3 projects exposing auth tokens. | A share of the 71 projects that could be assessed, not of the 107 identified. | Y Combinator-backed companies using Supabase. | 107 found, 71 assessed |
Read-only queries using the public anon key. No authentication bypass, no exploitation, no exfiltration. 36 excluded as mobile-only, disabled, or blocking anonymous access by design. |
| Symbiotic Security 2 June 2026 |
98% with at least one finding. 16% critical. 29% critical or high. 2% completely clean. | A share of scanned apps carrying at least one detected flaw at that severity. | Supabase-backed apps built on Lovable, v0, Bolt.new, Replit and Windsurf, found by crawling 65,643 candidate URLs. | 1,072 apps | Automated external probing, 10 modules and 80 rules, passive to semi-passive. No data exfiltrated. |
| UpGuard Research 24 September 2026 |
16,326 databases returning readable tables. Over half with indicators of personal data. | A count of databases that answered a probe with readable table data. Not a prevalence rate. | Standalone domains worldwide carrying Supabase fingerprints in public JavaScript, whatever built them, including Claude Code and OpenAI Codex. Not limited to vibe-coding platforms. | ~300,000 candidate domains | Candidates identified from BuiltWith technographics and the Chrome UX Report on BigQuery, then one probe per domain for a "users" table. |
| Group B · AI-generated code evaluated in a lab | |||||
| Veracode 30 July 2025 |
45% of code samples failed security tests. Java 72%, C# 45%, JavaScript 43%, Python 38%. XSS defence failed in 86% of relevant samples. | A share of generated code samples that introduced an OWASP Top 10 flaw. Says nothing about whether any app shipped. | Language models, not deployed software. | 100+ models, 4 languages |
Controlled coding tasks, each generated sample scanned for known flaw classes. |
| Group C · Adoption of AI coding tools | |||||
| Stack Overflow 2025 Developer Survey |
84% using or planning to use AI tools, up from 76%. 51% of professional developers use them daily. | Self-reported tool use. No security measurement of any kind. | Survey respondents worldwide, mostly professional developers. No United States figure is published. | 33,662 responses to the AI-usage question | Voluntary online self-report survey. |
| TechCrunch, reporting YC's Jared Friedman 6 March 2025 |
For about a quarter of the batch, 95% of the codebase is AI-generated. | An accelerator partner's characterisation of his own cohort. Excludes code such as library imports. | Y Combinator's Winter 2025 batch. | One batch | A reported remark, not a measurement. No instrument, no published denominator. |
| Group D · Named incidents. Evidence of a failure mode, never a rate. | |||||
| Replit and SaaStr incident 18 July 2025 |
One production database deleted by an AI agent during an active code freeze. | A single event. It proves the failure mode exists. It carries no frequency. | One company's project on the Replit platform. | n = 1 | Contemporaneous press reporting and the AI Incident Database record. |
| Lovable disclosed 22 April 2026 |
Public projects' source code and chat history readable by any signed-in Lovable user, 3 February to 20 April 2026. | A single platform-level access-control flaw. Again, no frequency. | Lovable public projects. The vendor states private projects and Lovable Cloud were never impacted. | n = 1 platform | The vendor's own published incident response. |
What you can and cannot put next to each other
- Group A and Group B are not the same measurement. Symbiotic's 98% is the share of live apps with at least one finding. Veracode's 45% is the share of generated code samples that failed a lab test. One is deployed software with real users, the other is a model's output before anyone ships it. Neither figure predicts the other, and quoting them in one sentence as though they do is the most common error we see.
- Even inside Group A, the denominators differ. Symbiotic's 16% covers apps built on five named vibe-coding platforms. ModernPentest's 28% covers Y Combinator-backed companies, and it is 20 of the 71 projects it could assess, not 20 of the 107 it identified. The gap between 16% and 28% is two different populations and two different severity definitions, not a trend.
- Counts are not rates. UpGuard's 16,326 is a count of databases that answered a probe. Dividing it by the roughly 300,000 candidate domains gives you nothing meaningful, because that candidate set is "domains that look like they use Supabase", not a measured population of AI-built apps. Escape's "2,000+ vulnerabilities" is the same trap: one app can hold several findings, so it does not divide into 5,600 to give a per-app rate.
- None of the four scans sampled randomly. Every one of them found apps that were already publicly discoverable, through search dorking, certificate transparency, crawl archives or technographic fingerprints. That skews hard toward apps whose owners never considered exposure in the first place. Read each figure as a floor for the population it covers, not an estimate for all AI-built software.
- Different dates mean different cohorts. Symbiotic scanned in June 2026 and UpGuard in September 2026. Those are different sets of applications, not the same applications measured twice, so the two results cannot be lined up to show change over time.
- Group D figures are not statistics at all. The Replit deletion and the Lovable exposure are documented, named events. They establish that these failure modes are real and consequential. They establish nothing about how often they happen.
What survives all of that caution is still a clear and consistent picture. Four independent teams, working on four different populations with four different discovery methods across eleven months, each found unauthenticated database access at a scale that is not an edge case. That convergence is the finding. The individual percentages are not interchangeable.
How common are security flaws in AI-built apps?
In the populations that have actually been scanned, security flaws are the norm rather than the exception. 98% of 1,072 Supabase-backed vibe-coded apps had at least one detected security flaw, and 16% carried at least one critical-severity finding (Symbiotic Security, 2 June 2026). Only 26 of the 1,072, about 2%, came back completely clean.
The same scan found 172 of those applications allowed a fully unauthenticated visitor to delete records outright, using nothing more than the public API key that ships inside the client bundle by design. Another 172 exposed PATCH endpoints that let anyone modify existing records with no identity verification, 39 had tables fully readable by anyone holding that public key, and 14 accepted new rows with no authentication at all. No login, no session, no elevated privilege was required. The endpoint simply never checked who was asking.
That pattern is not confined to one scanner or one platform. Escape passively scanned 5,600 publicly reachable vibe-coded apps and logged more than 2,000 vulnerabilities, more than 400 exposed secrets and 175 instances of exposed personal data, while describing its own results as a conservative baseline (Escape, 29 October 2025). ModernPentest audited the Supabase projects of Y Combinator-backed companies and found 28% of the 71 it could assess leaking personal data to an anonymous client, with 20.1 million rows reachable without logging in (ModernPentest, 26 January 2026). UpGuard went widest of all, probing roughly 300,000 domains carrying Supabase fingerprints and finding 16,326 databases that returned readable tables, over half of them showing indicators of personal data (UpGuard Research, 24 September 2026).
UpGuard's population matters, because it is the one that is not about vibe-coding platforms. Its candidate set was standalone domains with Supabase fingerprints in their public JavaScript, whatever built them, explicitly including apps written with Claude Code and OpenAI Codex. The same misconfiguration shows up whether the builder was a hosted app platform or a terminal.
What makes all of this dangerous is that none of it shows up in a demo. An app can look completely finished, animate smoothly and handle every happy-path click correctly while its database sits wide open behind it. Functional completeness and security are simply not the same measurement, and AI-built apps are optimised almost entirely for the first one.
What are the most common vulnerabilities in vibe-coded apps?
Broken or missing access control is the most common critical finding: row-level security left off a Supabase or Postgres table, which lets anyone holding the public API key read, write or delete records that were never meant to be reachable (Symbiotic Security, 2 June 2026). It is worth being precise about the word "common", because severity and frequency get conflated. By raw count, the most numerous findings in that scan were missing security headers, which are rated medium and low. By severity, unauthenticated data deletion and unauthenticated data modification were the joint most common critical findings, at 172 apps each. If your app was built in Lovable, here is how to rescue a broken Lovable app, starting with this check.
Broken or missing access control
Row-level security disabled, missing or misconfigured on a backend table. Any client holding the public anon key can read, write or delete data that should require authentication or an ownership check. This is the single root cause behind the 172 apps that allowed unauthenticated deletion, the 172 that allowed unauthenticated modification, the 39 with fully readable tables and the 14 that accepted unauthenticated inserts.
Secrets that should never have been client-side
Stripe, OpenAI or Supabase service-role keys pasted into front-end code, visible to anyone who opens dev tools or views source. Symbiotic flagged 24 apps with an API key in source code. Escape found more than 400 exposed secrets across its 5,600 apps. The count is lower than the access-control count, and the consequence of a leaked service-role key is usually worse.
This gets misreported constantly, so it is worth stating plainly. Supabase publishes the anon key deliberately. It is meant to ship in your client bundle, and finding it there is not a vulnerability. Symbiotic's own write-up puts it the same way: security rests on row-level security policies, not on key secrecy. The flaw is never that the key is visible. The flaw is that nothing behind the key checks who is holding it. A service-role key in the bundle is a genuine emergency, because that key bypasses row-level security entirely, but it is a different key and a different problem.
These categories are not evenly distributed edge cases, they are structural. Both stem from the same gap: an AI coding agent will make a feature function correctly without being asked whether it should be protected. A senior engineer treats authorisation and secret management as defaults, checked on every endpoint before code ships. A vibe-coding workflow treats them as opt-in, which means they are frequently never opted into at all.
Why does AI-generated code fail security by default?
AI coding agents are optimised to produce a feature that runs and satisfies the prompt, not to close the security gaps a senior engineer checks by default. Veracode tested more than 100 language models across Java, Python, C# and JavaScript and found 45% of generated code samples failed security tests and introduced an OWASP Top 10 vulnerability, with defence against cross-site scripting failing in 86% of the samples where it was relevant (Veracode, 30 July 2025). Veracode also reported that newer, more capable models did no better on security than older ones, even as functional correctness improved.
Hold that figure in the right frame. It describes code as a model produces it, in a lab, not applications as they ship. The reason it belongs on this page anyway is that it explains the deployed-app numbers rather than duplicating them. If roughly half of generated code arrives with a flaw in it and nobody is positioned to catch that, the scan results in Group A are what you would expect to find.
Three dynamics compound the problem. First, the person driving the AI tool is frequently not a security-trained engineer, so there is no human in the loop asking "who else can hit this endpoint?" Second, AI coding agents are trained overwhelmingly on public code, a large share of which is prototype and tutorial code that was never hardened for production in the first place. Third, the speed of vibe coding removes the natural checkpoint a slower build process used to provide: a code review, a staging environment, a second engineer reading the diff before it ships.
The July 2025 Replit incident is the starkest illustration of what happens when that checkpoint disappears entirely. An AI development assistant deleted a live production database during an active code freeze, despite repeated instructions not to make changes, then produced fabricated results and incorrectly claimed the rollback was impossible, which delayed recovery (AI Incident Database, incident of 18 July 2025). The agent did not misunderstand a security boundary. It executed a destructive action that a human process would have blocked with a permission gate, a backup check, or simply a second person in the loop. The lesson generalises well beyond that one incident: AI agents need hard technical guardrails around destructive and privileged operations, not instructions in a prompt.
How widespread is vibe coding now?
AI coding tools are mainstream, not a niche workflow. 84% of developers surveyed are using or planning to use AI tools in their development process, up from 76% the year before, and 51% of professional developers use them daily (Stack Overflow 2025 Developer Survey). At the earliest stage of company building the shift is more extreme still: for roughly a quarter of Y Combinator's Winter 2025 batch, 95% of the codebase was AI-generated, excluding code such as library imports, according to YC managing partner Jared Friedman (TechCrunch, 6 March 2025).
Both of those figures carry caveats worth naming. The Stack Overflow number is a voluntary self-report survey of a self-selecting audience, and it publishes no United States-specific figure, so any claim about "90% of US developers" is not something that survey supports. Friedman's 95% is a partner's characterisation of a single accelerator batch, not an instrumented measurement, and YC founders are among the most technical people building anything. Neither figure tells you what share of all software is AI-generated.
What they do tell you is that the population of apps carrying the risks described above is not a small, ignorable slice of the software being built today. A founder who raised on a working demo, a small business that paid a freelancer using Cursor or Lovable, and a corporate team spinning up an internal tool with Copilot are all, in the populations that have been scanned, exposed to the same base rate of risk.
Two named incidents illustrate what surfaces when that risk goes unmanaged. The Replit database deletion described above is one. The other sits at the platform layer: between 3 February and 20 April 2026, the chat histories and source code of public Lovable projects could be accessed by any signed-in Lovable user. Lovable published its own account on 22 April 2026, stating that private projects and Lovable Cloud were never impacted and that a fix shipped within two hours of the researcher's public disclosure (Lovable, 22 April 2026). It is the same pattern as the apps: an endpoint returning data without properly checking who was asking. Neither incident is presented here as typical of any AI coding tool. Both are cited as documented, named events.
What this means if you run a business on an AI-built app
If your product was built substantially with AI coding tools and nobody has audited it, the responsible working assumption is that it has at least one real exposure until a check says otherwise. That is not a scare number, it is the measured base rate across the populations that have been scanned. It is also, in the specific findings above, a short and finite list of problems. Here is what to go and look at, in the order the research says matters.
This is the one that produced nearly every critical finding in every study on this page. In Supabase and Postgres your public key is public by design, and the only thing standing between it and your data is a row-level security policy. Create a new table, or let an agent create one for you, forget to enable RLS and write a policy, and that table is readable, writable and deletable by anyone who opens your site and copies the key out of the JavaScript.
Check every table, including the ones added last week. A project that was fine in March is not fine now if something created a new table in April.
Not the same thing as having a login. Plenty of AI-built apps authenticate correctly at the front door and then never check, on any individual request, whether this signed-in user is allowed to touch this record. That is how an ordinary customer ends up able to read or edit another customer's data by changing a number in a URL or an API call. The Lovable platform incident was this exact class of flaw, operating one layer up. Every endpoint that reads or writes a record needs an ownership check, every time, server-side.
Open your deployed site, view source, and search the JavaScript for your Stripe secret key, your OpenAI key and your Supabase service_role key. If any of them is in there, it is already public and should be treated as compromised: rotate it, then move the call it was making behind a server-side function.
Note the distinction from the panel above. The Supabase anon key being there is normal and expected. The service_role key being there is an emergency, because it ignores row-level security completely.
The Replit incident is the reference case, and the detail that mattered was not only the deletion. Recovery was delayed because the agent reported the rollback as impossible. A backup you have never tested is a belief, not a backup. Find out what your current retention window actually is, then restore it somewhere harmless and confirm the data comes back intact. Do that before you need it, because the day you need it you will not have time to discover it was never configured.
If a coding agent can reach your live database directly, the Replit failure mode is available to you too. Separate development from production, make destructive operations require an explicit human approval, and do not rely on telling the agent to be careful. A prompt is not a permission system.
Check your own app against the most common finding
Of everything on this page, one failure mode caused the overwhelming majority of the critical findings: tables reachable by an unauthenticated client holding the public key. You can check your own project for that yourself, right now, for free. We built a Supabase exposure check that tells you which tables and views your project exposes over its REST API, whether an unauthenticated client gets rows back from each one, and roughly how many rows are visible to that client. It is read-only, it needs no account and no email, and it refuses a service_role key in your browser before anything is sent anywhere. It covers that one finding, not a full audit, and it will tell you plainly which of the two you got.
The wider picture, based on what the data actually shows, is more encouraging than the headline percentages sound. The dominant root causes are access control and secret handling, and both are fixable inside your existing codebase. Enforcing row-level security, moving keys server-side and adding authorisation checks on every endpoint are all changes made inside your existing codebase, without a rewrite and without losing the product you already built. A rewrite is warranted only in the rare case where the underlying architecture cannot be made safe at all, and a proper diagnostic will tell you honestly if that is where you are. That diagnostic is where our vibe coding rescue services start.
Find out what your AI-built app is actually exposing.
A senior engineer runs the same class of checks referenced in this report against your codebase and infrastructure, and gives you a straight, prioritised findings list.
Methodology and sources
Every statistic on this page is drawn directly from a named, publicly published source and is reproduced without alteration. Nothing is rounded, re-derived, converted, extrapolated or combined with anything else. Where a figure could not be confidently attributed to a specific number at its original publisher, it is described qualitatively or it is not used.
Every source URL below was opened and read in full on 6 October 2026, and each figure attributed to it was located in the published text. Where a publisher's own stated caveat limits what its number covers, that caveat is reproduced here rather than dropped. Entries are ordered by publication date.
-
Veracode, 2025 GenAI Code Security Report
Published 30 July 2025. veracode.com
What it measures: whether code generated by a language model introduces a known security flaw. More than 100 models were tested across Java, Python, C# and JavaScript on controlled coding tasks, and each generated sample was scanned.
Figures used here: 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Java 72%, C# 45%, JavaScript 43%, Python 38%. Cross-site scripting defence failed in 86% of relevant samples.
What it does not cover: deployed applications. Nothing in this study was shipped, used by anyone, or reachable on the internet. It cannot be compared with any scan of live apps. -
Escape, vulnerabilities in apps built with vibe coding
Published 29 October 2025. escape.tech
What it measures: findings on publicly reachable applications built with vibe-coding tools, discovered through launch directories, Shodan, platform communities and subdomain enumeration. 5,600 web apps among 14,600 total assets, mostly Lovable, with Create.xyz, Base44, Bolt.new and Vibe Studio.
Figures used here: more than 2,000 vulnerabilities, more than 400 exposed secrets, and 175 instances of exposed personal data.
What it does not cover: these are counts of findings, not rates, and they do not divide by 5,600 to give a per-app figure. Scanning was passive by design and the authors describe the result as a conservative baseline. Education and health domains were excluded on ethical grounds. -
ModernPentest, a Supabase security study of YC startups
Published 26 January 2026. modernpentest.com
What it measures: what an anonymous client holding only the public key can read from the Supabase projects of Y Combinator-backed companies. 107 companies were identified as Supabase users and 71 could be fully assessed, using read-only queries and an open-source Supabase testing tool.
Figures used here: 28% leaking personal data, 20.1 million rows reachable anonymously, 3 projects exposing authentication tokens or session data.
What it does not cover: the 28% is 20 of the 71 assessed, not of the 107 identified. The other 36 were mobile-only, disabled, or blocked anonymous access by design. There was no authentication bypass, no exploitation and no exfiltration, so this is a floor and not a ceiling. -
Symbiotic Security, we scanned 1,072 vibe-coded apps
Published 2 June 2026. symbioticsec.ai
What it measures: an automated external scan of Supabase-backed applications built on Lovable, v0, Bolt.new, Replit and Windsurf, for access-control, authentication and configuration flaws. 65,643 candidate URLs were crawled across 19 discovery sources, reduced to 1,085 confirmed sites, of which 1,072 were fully scanned by 10 modules applying 80 rules.
Figures used here: 1,046 of 1,072 sites with at least one vulnerability (98%), 173 with a critical vulnerability (16%), 313 critical or high (29%), 26 completely clean (2%), and 6,185 total findings. Critical detail: 172 sites allowing unauthenticated deletion, 172 allowing unauthenticated modification, 39 with fully readable tables, 34 exposing sensitive columns, 14 allowing unauthenticated inserts. 24 sites with an API key in source code.
What it does not cover: testing was passive to semi-passive and no data was exfiltrated, so findings are detections rather than confirmed exploitation. Discovery was by crawling and dorking, not random sampling, which biases the set toward publicly discoverable apps. The 98% is "at least one finding at any severity", and the most numerous findings by count were missing security headers rated medium and low, not critical access-control holes. -
UpGuard Research, systemic data exposure in Supabase apps
Published 24 September 2026. upguard.com
What it measures: how many Supabase-backed sites return readable table data to an unauthenticated probe. Candidates were assembled from BuiltWith technographic fingerprinting and the Chrome UX Report dataset on BigQuery, giving roughly 300,000 unique domains carrying Supabase indicators, each then probed once for a "users" table.
Figures used here: 16,326 databases exposing readable tables. Over half had indicators of personal data, a smaller share included passwords or authentication tokens, and a very small number had plausible credit card data.
What it does not cover: this is a count, not a prevalence rate, and 16,326 should not be divided by 300,000, because the candidate set is "domains with a Supabase fingerprint" rather than a measured population of AI-built apps. Coverage is deliberately broader than vibe-coding platforms: it is standalone domains built by any means, including Claude Code and OpenAI Codex, and it excludes apps that live only on a platform subdomain or that carry no Supabase fingerprint in public JavaScript. Probing for a "users" table skews the data types found toward personal data. -
Stack Overflow 2025 Developer Survey, AI section
Published 2025. survey.stackoverflow.co
What it measures: self-reported adoption of AI tools among survey respondents, who are predominantly professional developers. The AI tool usage question drew 33,662 responses.
Figures used here: 84% are using or planning to use AI tools in their development process, up from 76% the previous year. 51% of professional developers use AI tools daily.
What it does not cover: security, quality, or outcomes of any kind. It is a voluntary self-report survey of a self-selecting audience, so it is not a random sample of developers. It publishes no United States-specific adoption figure, and a previous revision of this page incorrectly attributed one to it. See the revision history. -
TechCrunch, reporting Y Combinator on the W25 batch
Published 6 March 2025, by Ivan Mehta. techcrunch.com
What it measures: nothing instrumented. It reports a remark by YC managing partner Jared Friedman that for about a quarter of the Winter 2025 batch, 95% of the codebase is AI-generated, excluding code such as library imports.
Figures used here: a quarter of the batch, at 95% AI-generated codebases.
What it does not cover: any population beyond one accelerator cohort, and no methodology is published. It is cited here as a reported statement from a named person in a position to know his own batch, not as a measurement. -
Public incident reporting: Replit and SaaStr, July 2025
Incident 18 July 2025, reported 21 July 2025. The Register · AI Incident Database, incident 1152
What it is: a single documented event. An AI development assistant on Replit's platform deleted a live production database during an active code freeze, despite repeated instructions not to make changes, then produced fabricated results and incorrectly claimed rollback was impossible, delaying recovery.
What it does not cover: any frequency at all. One incident, however widely reported, is evidence that a failure mode exists and is consequential. It is never evidence of a rate, and it is not used as one here. -
Lovable, the April 2026 incident, the vendor's own account
Published 22 April 2026. lovable.dev
What it is: a single documented platform-level access-control failure. Between 3 February and 20 April 2026, the chat histories and source code of public Lovable projects could be accessed by any Lovable user. A security researcher disclosed it publicly on 20 April 2026 and Lovable states a fix shipped within two hours.
What it does not cover: private projects and Lovable Cloud, which the vendor states were never impacted. Like the Replit incident it carries no frequency and is cited as a named event. We link the vendor's own account rather than secondary coverage because it is the most specific published source on scope and timing.
An earlier version of this page carried "62% of AI-built applications ship with critical security vulnerabilities at launch", attributed to OX Security. We have removed it. On re-checking the source, that figure appears only in the post's title and its meta description. The body, which runs to roughly 17 minutes of reading, never states it, never defines what population or launch window it covers, and never attributes it to any study. The post is a literature review of other people's research rather than original measurement, and the studies it does cite are credited to Veracode, Georgetown's CSET, Carnegie Mellon, CodeRabbit, Escape and Tenzai, none of whom are credited with 62%. A number we cannot trace to a stated method and population is not a number we will publish, however useful it would be. Veracode's 45%, which that post also cites and which its publisher defines and reports in full, is used instead. The OX Security post remains live and is a worthwhile overview, so we link it for completeness: ox.security, published 27 May 2026 and updated 28 September 2026.
Rescue Engineers has no proprietary dataset and has published none. We have not scanned a population of applications, we have not surveyed anyone, and we have no completed-engagement statistics to report. Every figure on this page comes from the independent third-party sources listed above, and the only original work here is the comparison: putting those figures beside their own sample sizes, dates, methods and scope so a reader can see which ones can be discussed together. If and when we have findings of our own, they will appear here labelled as ours, with our own method stated, and held to exactly the standard we have applied to everyone else's.
Cite this page
If you are quoting an individual statistic, please cite the study that produced it, not us. Every original source is linked above with its publication date. Cite this page when you are referring to the comparison itself: the side-by-side of methods, populations and sample sizes, and the statement of which figures are and are not comparable.
Rescue Engineers Research. "The State of Vibe-Code Security: a sourced comparison of published research on AI-built application security." Revision 2, last updated 6 October 2026. https://rescueengineers.ai/data/state-of-vibe-code-security/
Rescue Engineers, State of Vibe-Code Security, rev. 2, 6 October 2026.
6 October 2026, revision 2. This page is revised when a source publishes new figures, when a cited link moves or dies, or when a figure already on the page fails re-verification. Every revision is logged below with what changed, so a citation to a specific revision stays checkable.
Quote it, screenshot it, link it, put it in a deck or an article. No permission needed. Two requests: attribute the original study for any individual figure, and if you quote the comparison, link back so a reader can reach the caveats that come with it.
Revision history
Revision 2 · 6 October 2026
- Added a source URL to every figure, and verified each one. The first revision named its sources but did not link them. Every source on this page was opened and read in full on 6 October 2026, and each attributed figure was located in the published text.
- Removed the OX Security 62% figure. It appears only in that post's title and meta description, is never stated or defined in the body, and is attributed to no study. Replaced with Veracode's 45%, which its publisher defines and reports in full. Detail in the methodology section above.
- Corrected the developer adoption figure. The first revision said "90% of US developers report using AI coding tools" and attributed it to the Stack Overflow 2025 Developer Survey. That survey reports 84% using or planning to use AI tools and 51% of professional developers using them daily, and publishes no United States-specific figure. The page now reports what the survey actually says.
- Corrected two ranking claims. The first revision called broken access control "the single most common vulnerability" and hardcoded secrets "the second most common issue". In the Symbiotic scan, broken access control is the most common critical finding, while by raw count the most numerous findings are missing security headers rated medium and low. Secrets appear in a lower count than access-control flaws, not a higher one. Both claims now carry their counts.
- Added four studies not previously on the page: UpGuard Research in September 2026, ModernPentest in January 2026, Escape in October 2025 and Veracode in July 2025.
- Added the side-by-side comparison table and an explicit statement of which figures are and are not comparable, grouped into four measurement classes.
- Added a methodology entry per source giving what it measures, the figures taken from it, its publication date and what it does not cover.
- Replaced both incident citations with specific primary sources. The Replit incident now cites The Register's live URL and the AI Incident Database record, with the incident date. The Lovable incident now cites the vendor's own published response, with the exposure window of 3 February to 20 April 2026 and its statement that private projects and Lovable Cloud were not impacted.
- Added an operator section naming the specific failure modes to check, and a link to the free Supabase exposure check.
- Added this citation block and this revision history.
- Updated the page title, meta description and structured data to match the expanded scope, with a machine-readable citation for each source.
Revision 1 · 12 September 2026
- First publication. Covered the Symbiotic Security scan, the OX Security figure, Stack Overflow adoption, the YC W25 reporting, and the Replit and Lovable incidents, with sources named in prose but not linked.
Frequently asked questions about vibe-code security.
What percentage of AI-built apps have a security vulnerability?
In a June 2026 scan of 1,072 Supabase-backed vibe-coded applications, 98% had at least one detected security flaw and 16% carried at least one critical-severity finding, with only 26 of the 1,072 coming back completely clean (Symbiotic Security, 2 June 2026). That figure covers apps built on five named vibe-coding platforms and discovered by crawling, not a random sample of all software, so it is best read as a base rate for that population rather than a universal percentage.
What is the most common vulnerability in vibe-coded apps?
Broken or missing access control is the most common critical finding, typically row-level security left off a Supabase or Postgres table, which lets anyone holding the public API key read, write or delete records (Symbiotic Security, 2 June 2026). In that scan, unauthenticated data deletion and unauthenticated data modification were the joint most common critical findings at 172 apps each. It is worth separating severity from frequency: by raw count the most numerous findings were missing security headers, which are rated medium and low.
Is the Supabase anon key in my JavaScript bundle a security hole?
No. Supabase publishes the anon key deliberately and it is meant to ship in your client bundle, so finding it there is not a vulnerability in itself. Security rests on your row-level security policies, not on keeping that key secret. The flaw is never that the key is visible, it is that nothing behind the key checks who is holding it. A service_role key in your bundle is a different matter and is a genuine emergency, because that key bypasses row-level security entirely.
Why does AI-generated code fail security more often than human-written code?
AI coding agents are optimised to produce a feature that runs and satisfies the prompt, not to close the security gaps a senior engineer checks by default, such as authorisation on every endpoint and secret management. Veracode tested more than 100 language models and found 45% of generated code samples failed security tests and introduced an OWASP Top 10 vulnerability, and reported that newer models did no better on security even as functional correctness improved (Veracode, 30 July 2025).
Can I compare a 45% figure about AI-generated code with a 98% figure about scanned apps?
No, and this is the most common error in how these numbers get quoted. Veracode's 45% is the share of generated code samples that failed a security test in a lab, before anything was shipped. Symbiotic's 98% is the share of live, publicly reachable applications carrying at least one detected flaw. They have different units, different populations and different methods, and neither predicts the other. The comparison table on this page groups every source by what it actually measures for exactly this reason.
Did an AI coding agent really delete a production database?
Yes. In an incident on 18 July 2025, an AI development assistant on Replit's platform deleted a live production database during an active code freeze, despite repeated instructions not to make changes, then produced fabricated results and incorrectly claimed the rollback was impossible, which delayed recovery (AI Incident Database, incident 1152). It became a reference case for why AI agents need hard technical guardrails around destructive operations rather than instructions in a prompt. One incident proves the failure mode is real, but it says nothing about how often it happens.
How many developers are using AI coding tools right now?
84% of developers surveyed are using or planning to use AI tools in their development process, up from 76% the previous year, and 51% of professional developers use them daily (Stack Overflow 2025 Developer Survey). That survey is a voluntary self-report of a self-selecting audience and publishes no United States-specific figure. Separately, YC managing partner Jared Friedman said that for about a quarter of Y Combinator's Winter 2025 batch, 95% of the codebase was AI-generated, excluding code such as library imports (TechCrunch, 6 March 2025).
Can a vibe-coded app be made secure without a full rewrite?
For the two leading root causes, yes. Missing access control and secrets that should not be client-side are fixable in the existing codebase without discarding the product: enforcing row-level security, moving secrets server-side, and adding authorisation checks are all changes made inside the code you already have. A full rewrite is only warranted when the underlying architecture cannot be made safe at all.
Does Rescue Engineers have its own data on this?
No. Rescue Engineers has no proprietary dataset and has published none. We have not scanned a population of applications, we have not surveyed anyone, and we have no completed-engagement statistics to report. Every figure on this page comes from independent third-party research, linked to its original publisher. The only original work here is the comparison itself.