Wiz: 1 in 5 Vibe-Coded Apps Has a Security Flaw

Wiz Research analyzed applications built on vibe-coding platforms and found that 1 in 5 organizations using them expose themselves to security risk. The vulnerabilities are not random. They recur in four specific patterns , client-side authentication, hardcoded secrets, permissive data access policies, and internal tools deployed publicly without authentication , which points to a structural problem with how these platforms generate code, not with how any individual developer wrote a particular file.

The four patterns Wiz found#

Wiz Research's findings are specific. Authentication logic gets handled entirely in the browser: the password is embedded in the JavaScript, visible to anyone who loads DevTools. Wiz documented real examples where passwords like "marketingdocs2025" appeared in plaintext in client-side files. Third-party API keys appear hardcoded in the same bundle. Supabase Row-Level Security policies get left at permissive defaults or disabled entirely, letting anyone with the project's anon key query sensitive tables. Internal dashboards and chatbots get deployed publicly because the platforms make deployment as easy as the build itself.

None of these are exotic. They are the first four things a security-aware engineer would check. The point is that builders on these platforms often lack that context, and the platforms until recently did not prompt for it.

20% is a floor, not a ceiling#

Wiz's number describes organizations with at least one high-impact misconfiguration. A separate audit of 35 vibe-coded apps published by Teyrex in July 2026 found SQL injection vulnerabilities in 95% of apps, hardcoded secrets in 80%, and unprotected API routes in 85%. A typical app carried 15 to 30 distinct issues. A report covering 21.6 million lines of AI-generated code, cited by BotBeat on July 14, found that 87% of AI-generated projects had at least one security finding, with only 56 of 424 projects completely clean.

The 20% figure from Wiz is probably the share that reached a severity threshold serious enough to call out explicitly. The underlying rate of individual vulnerability instances is far higher.

Why platform-level patterns matter more than per-PR review#

Traditional AppSec thinks in PRs. Did this change introduce a vulnerability? That framing misses what is happening here. When a platform's default behavior produces client-side auth in a predictable pattern, a single scan rule catches it across every app the platform has ever generated. The attack surface is the platform, not the individual developer.

Writing in July 2026, Richard Beck at QA.com put it directly: "An insecure implementation generated once can quickly become an insecure implementation generated thousands of times." That is the structural problem. The LLM does not know what security controls are missing from the prompt. It generates what it was asked for. Security intent was never part of the input.

This is also why the Teyrex data found no meaningful difference in safety between tools. Cursor was identifiable in roughly 35% of the 35 audited codebases, Lovable in about 10%, and the majority showed traces of several tools layered together. The finding: by the time an app reaches an audit, the question is not which tool wrote it, but whether anyone ever reviewed what was written.

Vibe coding is no longer just hobbyist territory#

Andrej Karpathy described vibe coding in February 2025 as appropriate for throwaway weekend projects. The pattern that has emerged since is that the same workflow builds the internal tool that fourteen people now depend on, and nobody notices the distinction until something leaks. Wiz found internal chatbots trained on sensitive corporate data, internal knowledge bases exposing proprietary documents, and admin dashboards deployed publicly , all built on Lovable, all publicly fingerprintable.

That shift matters for how engineering leaders should categorize the risk. A weekend project with a hardcoded API key is a personal problem. An internal HR tool with the same flaw, touching employee records, is a compliance event.

What autonomous code review catches here#

The vulnerability classes Wiz documented , hardcoded secrets, unsanitized inputs, client-side authentication , are exactly what deterministic scanning catches reliably. They leave consistent fingerprints in the AST. The pattern does not change based on which platform generated the code or which developer touched it last.

Hyrax's six agent domains include security as a primary focus. Its scanning covers hardcoded credentials, exposed API keys, and input sanitization gaps across the entire codebase, not just the files changed in the most recent PR. Where Wiz's research changes the calculus is in the framing: if a platform has been generating client-side auth for the last eighteen months, the question for an engineering leader is not whether the latest PR is safe. It is whether the entire class of apps built on that platform needs a targeted scan now. Hyrax submits the fix as a PR. The team merges. No auto-merge.

The 20% number Wiz produced is now a defensible benchmark. Engineering leaders have something concrete to bring to a board conversation about AI coding risk, a specific percentage, a specific set of failure patterns, and a specific platform category to point at. That is more useful than another general warning about AI-generated code quality , of which there has been no shortage.

Hyrax is live at hyrax.dev.