Evidence review · Updated July 25, 2026

State of Vibe-Coded Security 2026

This report separates VibeScan's May 2026 early sample of 61 completed URL scans from external vendor disclosures and published research. It describes recurring risks; it does not estimate the security of every AI-built app.

Scan my app freeRead the guides →

The live total is read from completed scans when this page loads. It counts normalized, unique public URL targets and excludes rechecks. Research statistics below stay frozen to the 61-scan May sample for an honest comparison.

87%

of early VibeScan scans (53 of 61) lacked the standard HTTP security-header set

Passive public-surface scans completed May 2026. An observational, self-selected sample—not a representative prevalence study.

14

critical findings across the early sample

6

high-severity findings across the early sample

879

total findings, including repeated low-risk checks

Methodology

Three numbers appear across VibeScan and are never pooled into one prevalence rate:

  • 1.Published early sample: 61 completed passive URL scans from May 2026. This research denominator is frozen. Counts are scanner findings, not confirmed exploits, and one app can contribute multiple findings.
  • 2.Live product total: unique normalized public URL targets with a completed scan. Query strings, fragments, protocol differences, and trailing slashes are deduplicated; rechecks are excluded. This operational count is not added to the 61-scan research sample.
  • 3.External evidence: linked vendor disclosures, NVD records, published studies, and academic research. The 1,645-app Lovable study is Matt Palmer's external research, not a VibeScan scan count. Each claim remains attributed to its source and methodology.
  • ·VibeScan — 61-scan early sample (May 2026)
  • ·Lovable — response to the April 2026 public-project access incident
  • ·NVD — CVE-2025-48757 (disputed Lovable-generated-site RLS record)

What we did not do:exploit live apps, access private user data, or conduct unauthorized testing. VibeScan's URL mode is a fast first-pass review, not a penetration test, and cannot prove that any specific app is fully secure. The sample is self-selected and should not be generalized to all AI-built apps.

Six recurring risk classes

Direct sample counts are labeled separately from risks described by external sources.

01

Exposed secrets in client-side code

CRITICAL
14 critical findings

API keys, database connection strings, Stripe secrets, and third-party tokens embedded directly in JavaScript bundles served to every visitor. AI tools generate working code. The fastest path is often to put credentials inline.

Real incident:Enrichlead (Cursor-built): Compromised within days of launch. Subscription logic bypassed and API keys maxed out. The attack vector was a plaintext key visible in the bundled JavaScript.
Also:r/nextjs: A developer discovered their Postgres connection string, Stripe secret, SendGrid key, and AWS key had been live in their production bundle for three weeks.
Fix:Move all credentials to environment variables server-side. Run VibeScan to check whether your deployed bundle exposes anything now.Check my app →
02

Missing security headers

HIGH
53 of 61 scans

HSTS, CSP, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy are absent on the majority of AI-built apps. These headers are not set by AI tools by default. They require explicit configuration. Without them, browsers cannot enforce the protections they are designed to provide.

Real incident:VibeScan early sample: 53 of 61 completed scans lacked the standard HTTP security-header set checked by the scanner.
Fix:Add security headers to your deployment config. For Vercel, add a headers() block in next.config.js. VibeScan checks these on every URL scan.Check my app →
03

Supabase RLS misconfiguration

CRITICAL
2 exposed tables

Row Level Security is enabled. But the policies say USING (true), which grants every row to every user regardless of who they are. AI tools generate syntactically correct RLS policies that are semantically open. Developers see "RLS enabled" and assume they are protected.

Real incident:CVE-2025-48757 describes a disputed 2025 Lovable-generated-site RLS issue. Separately, Lovable disclosed that a February 2026 regression exposed source code and chat history for public projects until April 20, 2026.
Also:Moltbook (Lovable-built): 35,000 emails, 1.5 million API tokens, and private messages leaked. Including plaintext OpenAI keys.
Fix:Audit every RLS policy. USING (true) means open to everyone. The correct pattern is USING (auth.uid() = user_id). VibeScan checks public Supabase surface exposure.Full guide →
04

Auth gaps and inverted logic

HIGH
Requires source review

A missing ! operator can block authenticated users while permitting anonymous ones. Frontend-only role checks can also hide an admin interface without protecting its API. Passive URL scanning can surface symptoms, but confirming authorization logic requires source review or authenticated testing.

Real incident:ShipSafe reports critical findings in its Cursor-app study. Treat its published percentage as that vendor's study result, not a prevalence estimate for all AI-built apps.
Fix:Review every route guard. If the condition checks role or authentication, verify the logic inverts correctly. VibeScan checks for common auth exposure patterns on public endpoints.Check my app →
05

Exposed admin and debug endpoints

HIGH
62 exposures

Admin panels, debug routes, and internal API endpoints left publicly accessible. AI tools generate scaffolding quickly. Routes intended for internal use often have no authentication guard applied because the developer did not specify one.

Real incident:Base44 BOLA (Broken Object Level Authorization): Admin endpoints accessible without authentication. Attackers could enumerate and modify other users' resources by iterating over predictable IDs.
Fix:Audit every route in your app. Any route that reads or writes user data must verify session and ownership server-side. Not just hide the UI. VibeScan checks for common exposed endpoint patterns.Check my app →
06

Vulnerable dependencies and supply chain

HIGH
67 advisory matches

Outdated packages with known CVEs, malicious MCP server integrations, and plugin injection attacks. AI tools recommend and install packages based on training data. This may include deprecated or compromised packages. MCP integrations introduce a new attack surface that has no existing tooling.

Real incident:CVE-2025-54136 (Cursor): A malicious MCP configuration file triggers remote code execution. No user interaction beyond opening a project required.
Also:OpenClaw plugin attack: 1Password tokens exfiltrated through a compromised Cursor plugin. Developers who installed the plugin granted filesystem access to the attacker.
Fix:Audit installed packages and MCP integrations before shipping. Paste your lockfile into VibeScan for exact-version CVE matching against known advisories.Check my app →

Platform breakdown

This table summarizes documented examples. It is not a comparative platform ranking.

PlatformTop issueCVEsEvidence
LovableRLS misconfiguration + BOLA170+ apps exposed in April 2026 incidentCVE-2025-48757Documented
BoltMissing security headersNo independent security analysis published yetNone filed publiclyLimited data
CursorRCE via MCP + inverted auth67% of audited apps had critical vulnerabilities (ShipSafe)CVE-2025-54136, CVE-2025-54135Documented
Claude / Claude CodeMCP RCE + auth endpoint gapsMCP file bypass and RCE disclosed Feb 2026 (Check Point)CVE-2025-59536, CVE-2025-59944Documented
v0 / VercelReact Server Component data leaksReact2Shell: source disclosure + DoS in Next.js 15–16 (Dec 2025)CVE-2025-55182, CVE-2025-55184Documented

Who is most at risk

Solo founders shipping to real users

Building fast is the point of AI tools. The gap between 'it works' and 'it is secure' is widest when there is no second set of eyes on the code.

Apps that handle payments or auth

Stripe keys in client bundles, open RLS on a users table, and inverted auth on a subscription check. Any one of these is a critical incident.

Apps built by non-engineers

AI tools are explicitly marketed to non-technical builders. Security defaults that require developer configuration are invisible to this audience.

Apps deployed to production in under 48 hours

The faster the ship cycle, the fewer the checkpoints. The average vibe-coded app goes from idea to live URL in one session.

What to do before you launch

1

Run a URL scan on your deployed app

Check what your public surface actually exposes. Headers, endpoints, bundle contents.

2

Audit every Supabase RLS policy

USING (true) is open to everyone. Every policy should scope to auth.uid() = user_id or equivalent.

3

Paste your lockfile and check CVEs

Your AI builder installed packages based on its training data. Some of those have known vulnerabilities now.

4

Check every route guard for inverted logic

If a condition gates by role or auth, read it twice. The missing ! is a common AI-generated mistake.

5

Verify security headers are set

HSTS, CSP, X-Frame-Options, X-Content-Type-Options. None are set by default in most AI-generated apps.

6

Move all credentials server-side

If a key is referenced in a client component or exported from a route, it is in the browser bundle.

Free audit

Get a free full report for your app

We’re running free audits with early users. Leave your email and we’ll send you the full paid-tier report. Fix prompts included, no credit card needed.

No spam. Unsubscribe any time. Spots are limited.

Check your own app

Free scan in 30 seconds. Paste a URL, your AI builder output, or a lockfile. No GitHub access needed.

Scan my app

Free preview · Fix prompts and recheck from $9

Not a penetration test. Fast first-pass review of your public surface and the artifacts you provide.

Sources