Vibe Coded Apps Security Statistics: 26 Real Audits

Twenty-six real apps built with AI coding tools, audited June through July 2026, every finding checked against the code before it counted: that’s the AxonBuild corpus, and this post is the full ledger, told once, with every denominator attached. Zero of the 26 came out green. Twenty-two carried at least one confirmed-critical finding. The mean score was 52 out of 100, and the range ran from 29 to 81. Even the 81 wasn’t green.

Search for vibe coded apps security statistics and every result is someone else’s number: a vulnerability count with no denominator, a percentage with no cohort described, a scan with no verification step behind it. None of them print the honest counter-direction: which apps came back clean, and how often the scary-looking finding wasn’t real. This post prints both, because a study that only ever reports catastrophe is a marketing page wearing a methodology section.

The headline numbers

Zero of 26 real vibe-coded apps came out green, including the five I built myself.

Where these vibe coding security statistics come from

Three cohorts, run through the identical audit. Eleven third-party apps make up the deep-audit corpus: exhaustive, all 12 pillars scored, the set the pattern library was built from. Ten more are held-out validation, disjoint apps the engine had never seen, audited blind to check whether the method generalizes. The last five are mine, run through the same audit before I ever pointed it at a stranger’s repo.

The audit engine is automated. Every finding it produces is then human-verified: pinned to a file and line, commit hashes behind anything found in git history, checked against the code rather than pattern-matched. A candidate only counts once I’ve tried to disprove it and failed. That refutation discipline is what the false-positive row above is measuring: on the 10 held-out apps, zero findings failed verification, recall 1.0 against hand-checked ground truth. The deep-audit corpus was independently re-verified 36 times afterward, with zero regressions.

The distribution: scores 29 to 81

A mean of 52 hides more than it shows, so here’s the shape underneath it. The worst score, 29, belonged to a medical-advice app storing patient records in plaintext next to an account-takeover bug reachable from the open internet. The best, 81, was a thin freelancer dashboard with no backend at all: nothing to leak because nothing was real yet, which is its own kind of finding. Even that one wasn’t production-ready, just unfinished instead of unsafe.

The median, 51, sits almost exactly on the mean, which rules out the comforting story that one catastrophic outlier drags an otherwise-healthy group down. There’s no long tail here. The middle of this distribution is unremarkably mediocre, and that’s a worse fact for the category than a single bad app would be. The counts and the shape are this page’s job; what a vibe coded app looks like when someone reads the code takes eight of them one at a time instead.

What actually fails (the stereotype is backwards)

The stereotype puts leaked keys at the top of the failure list. In this corpus they sit at the bottom: across the 21 third-party apps, secrets was the best-scoring pillar of twelve, averaging 84 out of 100.

Pillars that don’t apply to a given app (no payments, no AI surface) are excluded from its average rather than counted as a zero, which is why the sample size differs by row. Revenue and billing carries a warning label instead of a verdict: three scored apps is a story, not a trend. The pattern that does hold across all twelve rows: vibe-coded apps mostly keep their keys where they belong. What they skip is the invisible engineering no prompt ever asked for: reliability, dependency hygiene, deployment gates, the part a demo never shows you. Why AI coding tools ship security holes by default is the mechanism behind that split; this post stays with the numbers.

Vibe coded apps security issues, ranked in the source ledger’s own order

The most common confirmed vibe coded app vulnerabilities across 26 audited apps: zero working automated tests in at least 23, no error tracking in 17 of 21 third-party apps, and an AI denial-of-wallet path in 12 of the 14 with an AI surface. The table below ranks all twelve patterns, each with the denominator that makes its rate checkable.

The two AI-specific rows matter most if you’re shipping an AI feature: a metered endpoint with no login is a bill with no ceiling, and a model that takes untrusted user text as an instruction will follow it. Both are vibe coding security risks that generic guidance still doesn’t name, and both sit near the bottom of the pillar ranking rather than in the leaked-key headline. The error-tracking row gets its own full treatment in when your app fails silently and says 200 OK; here it’s one row among twelve.

The sentences no other study prints

Every competing vibe-coding security number I could find points one direction only. Escape.tech’s scan of 5,600 vibe-coded apps (October 2025) reports 2,000-plus vulnerabilities and 400-plus leaked secrets, no clean result on the page. Symbiotic Security’s scan of 1,072 Supabase-backed apps (June 2026) is the rare exception that notes 26 clean apps, 2 percent, as a bare presence-or-absence count: markers detected, not exploited or individually confirmed, no false-positive rate, no score for the other 98 percent. OX Security’s widely quoted headline, “62% of AI-generated code ships with vulnerabilities,” never states a sample size in the body text under it. That’s the genre: a number built to be scary, not checked.

Here’s the honest counter-direction from this corpus. Four of the 26 apps came back with no confirmed critical at all, an honest finish list instead of a landmine. And in 3 of the 21 third-party apps, dependency scanners flagged 33 to 44 known CVEs each, pages of red. I traced every one. Reachable from the app’s actual code: zero. One of those three cry-wolf apps is also one of the four that scored clean overall, its own small proof of the discipline: a scanner can throw forty advisories at a codebase a verified audit clears in full, and the honest move is to say so in writing rather than pad the count.

Before you repeat a security statistic, ask three questions of it: what got counted, how each finding was checked, and how often the answer came back clean.

I ran it on my own five apps too

None of this data would mean much if I’d only ever pointed the engine at strangers. My own five production apps went through the identical audit, and every one of them came back red: scores of 36, 43, 49, 53, and 63.

The 36 stung the most, because I know exactly why it happened. That app runs live coaching sessions behind a properly wired enterprise SSO login. Underneath it sat a leftover side-door: a five-digit numeric code, generated with nothing stronger than a basic random-integer call, checked with no rate limit and no lockout. Ninety thousand possible codes and no throttle between guesses was all that stood between a stranger and a full account takeover, and the codes themselves sat in the database unhashed. The front door was the one I’d point to in a sales call. The side door is the one that would have gotten someone in.

That’s the finding that stays with me from my own five: good work in one place buys you nothing in another. The method didn’t soften because the app was mine.

What this data can’t tell you

Twenty-six is a real corpus and a small one. It’s large enough to support a count and a mechanism (“9 of 26 ran a reachable known-CVE version”) and too small to support a population claim about every AI-built app everywhere, so I don’t make that claim. The sample isn’t random either: the third-party apps are public projects builders shipped in the open, plus my own five, which skews toward web apps on Supabase- and Lovable-style stacks. There are no mobile-app audits in this set yet, and no single platform in the corpus is large enough to earn its own broken-out percentage.

One more caveat belongs here rather than buried in a footnote: the recall-1.0 figure is confirmed-findings recall against hand-checked ground truth, not recall against defects I planted on purpose to test the engine. Those are different claims, and I’d rather state the narrower one.

None of that makes the numbers above less real. It means the honest use of them is as a study of what vibe-coded apps do, not a verdict on any one app you haven’t checked. Whether that pattern holds for your specific app is a different question, and this post isn’t where it gets answered. The yes-or-no version, whether vibe-coded apps are safe at all, is a verdict question with its own separate answer built on this same data. A launch-readiness checklist for an AI-built app turns this same corpus into a checklist rather than a ledger; what a vibe coding security audit actually finds and whether an AI app security audit is worth paying for are the two decisions this data feeds most directly. If you want your own number instead of the corpus average, the scorecard scores what it can measure from your answers in about two minutes, and this same fixed-scope review is what runs behind the Beyond the Demo Audit when it’s pointed at your repo instead of someone else’s.

Common questions about these vibe coding security statistics

How secure are vibe coded apps, based on real audits?

Not very, and it’s checkable rather than a matter of opinion: 22 of 26 real apps carried at least one confirmed-critical finding, scores ran 29 to 81 out of 100, and not one, including my own five, came out green. “Secure” turned out to mean something narrower than most founders expect: the keys were usually fine, the tests and monitoring almost never were.

How many vibe coded apps are insecure?

In this corpus, 22 of 26. The four that weren’t red still weren’t finished: no confirmed critical, but a real list of gaps left to close before real users and money should depend on them. Zero came out both green and complete.

Are these vibe coding security statistics still accurate months later?

The window is June and July 2026, and AI tools change quickly, so treat this as a snapshot rather than a permanent law. The mechanism behind the numbers, tools optimizing for a working demo rather than a monitored, rate-limited production app, is structural rather than tied to one model version, which is why I’d expect the shape to hold even as the exact percentages drift.

Where do these numbers actually come from?

Every stat on this page traces to the same public methodology page: the corpus size, the three cohorts, the verification protocol, and the honest limitations, all in one place, so nothing here has to be taken on faith.