71% of AI-built apps have critical flaws. The scan data explains why.

Two large scans published in June 2026 put hard numbers on what security researchers have been warning about for eighteen months. The results are not a distribution of minor findings across a long tail of edge cases. They describe a category of software that ships broken, by default, at scale , and a toolchain that has no mechanism to notice.

What the scans found#

Launch Ready Code scanned 127 vibe-coded apps between March and June 2026 using non-invasive URL-based analysis scored against CVSS v3.1. Seventy-one percent , 90 of the 127 , carried at least one P0 finding. P0 means severe enough to cause a full data breach, account takeover, or regulatory incident. The average app carried 2.3 critical findings and 4.7 high-severity findings. Only 15 apps scored above 80 out of 100; 34% scored below 50.

Escape.tech covered a larger surface area , 5,600 apps , and found over 2,000 vulnerabilities, 400-plus exposed secrets including API keys and credentials, and 175 instances of personally identifiable information leaking through endpoints. Georgia Tech's Vibe Security Radar recorded CVEs linked to AI-generated code climbing from 6 in January 2026 to 35 in March 2026.

The three failures that repeat across every platform#

The Launch Ready Code data is most useful for what it shows about frequency. Missing HTTP security headers affected 84% of apps. No rate limiting on auth endpoints: 68%. Supabase Row Level Security disabled on at least one table: 47%. These numbers are not driven by a single bad platform , they appear across Replit, Lovable, Cursor, and Bolt, in that order of severity.

The OWASP 2023 data provides a baseline. Auth failures appear in roughly 25% of audited enterprise applications; in the vibe-coded cohort, the rate is 68%, about 2.7x higher. Broken access control appears in roughly 20% of enterprise audits; Supabase RLS disabled shows up at 47%. The comparison is imperfect , enterprise apps are larger, older, carry more legacy surface , but the vibe-coded apps in this dataset are smaller and newer, factors that typically reduce vulnerability count. They still significantly exceed enterprise baselines on the most fundamental controls.

Why the tools produce this output#

AI coding platforms are optimized for a single signal: does the application function? Rate limiting does not affect whether a login form works in development. Supabase RLS does not affect whether a query returns data during a demo. HTTP security headers do not affect whether a React bundle renders. None of these controls are visible to a tool testing its own output against the criterion of "it runs."

This is not a failure of intent. It is a structural consequence of the optimization target. Developers who configure their own deployment pipelines , the Bolt and Cursor cohort in this data , score higher because the extra manual step creates an intervention point where platform-level security configuration sometimes gets added. Developers using fully managed deployment flows skip that step, and the tool never flags what is missing.

The Lovable case is the most specific illustration. Lovable's tight Supabase integration generates schema and client code that works correctly in the prototype context but does not scaffold Row Level Security policies. The data shows RLS disabled in 61% of Lovable apps with Supabase integrations , the highest platform-specific concentration of any single vulnerability class in the report. The tool produces a functional product. The tool does not produce a safe one.

The breach record confirms the pattern#

In February 2026, Moltbook launched as an AI social network. Wiz researchers found the app had exposed 1.5 million API authentication tokens, 35,000 email addresses, and private messages , within three days of launch. The cause was a misconfigured Supabase deployment with RLS never enabled. Wiz concluded that every account could be hijacked with a single API call.

Quittr, a habit-tracking app that reached $1 million in revenue within 10 days and received an Oprah mention, was later found to have a publicly readable Firebase database. Any user's data was accessible without authentication. More than 39,000 users were at risk.

These are not obscure projects. They are apps with real user bases, real revenue, and real press coverage. The security posture at launch was identical to the median app in the scan data.

Where the review layer fits#

The scan data shows exactly what a security review layer should catch before a repo deploys. Hardcoded API keys in client-side bundles. Wildcard CORS on authenticated routes. Missing Content-Security-Policy headers. Supabase tables with RLS disabled. Auth endpoints with no rate limiting. None of these require a penetration tester or a security specialist. They require a scan that runs before code ships.

This is what Hyrax does. The security agent domain checks exactly this class of finding , exposed credentials, permissive CORS, missing security headers, insecure direct object references , across every file in the repository, not just the surface exposed to a URL scanner. Hyrax runs 13 verification steps before submitting a fix as a PR. The developer merges. Nothing auto-deploys.

The 12% of apps in the Launch Ready Code data that scored above 80 all had one thing in common: manual security review at some point before the scan, by a technical co-founder, a fractional CTO, or a code review process targeting this specific finding class. That is the control that is missing from the rest. It does not need to be manual.

Hyrax is live at hyrax.dev.