Vibe Coding Security
Vibe Coding Security
One-line summary: Systematic research scanning 5,600+ publicly deployed vibe-coded apps found 2,000+ vulnerabilities, 400+ exposed secrets, and 175 instances of PII (including medical records and IBANs) — almost entirely traceable to misconfigured Supabase Row-Level Security and exposed JWT tokens in frontend bundles. The category has a real, measurable, shipped-to-production security problem.
The insight
Vibe-coding tools abstract infrastructure, and the abstraction includes security defaults. When non-developers ship apps they didn't read the source of, the default configuration determines the attack surface. Empirically, those defaults are wrong often enough that a systematic scan finds thousands of exploitable apps. This is not a hypothetical risk; it's the current state of a large public sample.
The primary evidence — Escape.tech's systematic scan
From 2026-04-21-autoresearch-vibe-coding-app-builders (primary: Escape.tech — Methodology: 2k+ Vulnerabilities in Vibe-Coded Apps):
- Scope: 5,600+ publicly available apps analyzed; 14,600 total assets scanned via domain harvesting (launched.lovable.dev, Shodan, Reddit), subdomain enumeration, fingerprinting detection, web crawling, static frontend analysis, and DAST scanning.
- Sample distribution:
- Findings:
- 2,000+ security vulnerabilities.
- 400+ exposed secrets — API keys, service role credentials.
- 175 PII instances — including medical records, IBANs, phone numbers, emails.
- Dominant failure pattern:
- Exposed Supabase anonymous JWT tokens in shipped JavaScript bundles (expected when RLS is properly configured; dangerous when it isn't).
- Misconfigured Row-Level Security (RLS) policies turning the exposed token into effective full database access.
- Missing/weak authentication, unauthenticated API access, improperly secured PostgREST APIs.
Recommendation from the research: "Manually review auto-generated RLS policies." This is a non-trivial ask of the non-developer audience these tools target — a classic abstraction/competence mismatch.
Broader attack surface — attack classes named in Kaspersky's analysis
From 2026-04-21-autoresearch-vibe-coding-app-builders (Kaspersky — Security risks of vibe coding):
Package hallucination → typosquatting
"AI often suggests libraries that do not exist. This is called package hallucination. Attackers sometimes create real packages with those fake names. This is a typosquatting attack that creates a backdoor."
Mechanism: the LLM invents a library name, the user accepts the generation, the generated import resolves to a malicious package that didn't exist until an attacker squatted on the hallucinated name. Attack is automated — the attacker monitors common hallucinated names and publishes malicious packages preemptively.
Prompt injection via shared context / long-term memory
Malicious instructions stored in source-code comments or documentation are re-read by the agent later and executed as if from the user. Demonstrated against Windsurf ([CVE not named]).
Supply chain compromise via AI-generated code
The Nx platform compromise used a "vulnerability introduced by a simple AI-generated code fragment" to steal tokens and distribute trojanized tool versions. The AI fragment was legitimate-looking but introduced a specific weakness attackers exploited.
Vendor-specific CVEs and incidents (from the same Kaspersky analysis)
| Vendor | Issue |
|---|---|
| cursor | CVE-2025-54135 — arbitrary command execution via active MCP servers |
| Anthropic MCP server | CVE-2025-53109 — arbitrary file read/write on developer disk |
| Windsurf | Prompt injection via code comments persisted in long-term memory |
| Amazon Q Developer | Briefly contained "instructions to wipe all data" from developer computers before removal |
| replit-agent | Production database deletion (Jason Lemkin / SaaStr, July 2025) — "insufficient separation between test and production environments" |
| Enrichlead | 100% AI-generated code contained "newbie-level security flaws" allowing unauthorized feature access |
| Tea app | Major data leaks from misconfigured external database permissions |
Design implications
- Security is a non-default property of vibe-coded apps. Shipping an RLS-correct app requires the user to know what RLS is — which many non-developer users do not.
- The "manually review auto-generated RLS policies" recommendation is structurally weak. Research treats it as a mitigation; in practice, it's a bet against the target audience's skill level.
- Vendors owe stronger defaults. A vibe-coding tool that ships 4,000 apps of which a meaningful fraction have exploitable RLS has a product-quality problem, not a user-problem. The question is whether the vendor or the user bears the remediation cost.
- Attack economics favor attackers. Supabase RLS errors can be detected automatically via DAST scans (as Escape.tech demonstrated at scale). If one security research team can find 2,000 vulnerabilities in a sample of 5,600, malicious actors can run the same scan.
- Package hallucination is a novel supply-chain vector. It bypasses traditional supply-chain defenses (dependency audit, SBOM) because the malicious package wasn't introduced via a trust chain — the user created the trust chain by naming the package into existence.
Contradictions / tensions
- Sample skew vs. risk generalization. The Escape.tech sample is 70%+ Lovable because Lovable has the most public apps to scan — not because Lovable is necessarily less secure than other platforms. The underlying risk (exposed backend credentials + misconfigured RLS) generalizes to any Supabase-style architecture.
- "400+ exposed secrets" is a lower bound, not a ceiling. The research covered publicly scannable apps; private or authenticated-only apps with the same misconfiguration would not be visible to the scanner.
- Vendors' response is uneven. Replit shipped one-click restore after the SaaStr incident. No equivalent post-incident product changes have been documented for Lovable or the other platforms despite the Escape.tech evidence.
Open questions
- Do vibe-coding vendors have a duty of care that tier-1/2 code assistants don't? cursor and claude-code produce code their users can review; Lovable and Bolt.new produce apps their users often can't. The liability question is open.
- What percentage of vibe-coded apps are behind authentication and thus outside the scanner's reach? The 2,000-vulnerabilities number likely understates real exposure.
- Is there a safe default-configuration a vibe-coding tool could ship that would eliminate the RLS-misconfiguration class entirely? Or is the Supabase-plus-JWT model fundamentally user-burdening?
- Are these vulnerabilities being actively exploited? Escape.tech identified them; whether attackers have already automated exploitation is unknown in the sources.
- Do tier-1 code assistants have the same risk profile? Kaspersky's CVE list includes Cursor and Windsurf — so not a vibe-coding-only problem. But the blast radius is larger in vibe-coded apps because users can't read the code.