Vibe Coding CVE List and the Georgia Tech Vibe Security Radar

Search for a "vibe coding CVE list" and you're really asking a sharper question: is there a catalog of the vulnerabilities that AI-built apps keep shipping, and how do I check my app against it? This explainer answers both — what a CVE actually is and why vibe-coding flaws mostly don't get one, what efforts like the Georgia Tech Vibe Security Radar are trying to do, and how to check your own app against the recurring patterns that matter.

Why there isn't a traditional CVE list for vibe coding

A CVE (Common Vulnerabilities and Exposures) identifier is assigned to a specific, disclosed vulnerability in a named, shared piece of software — a library, a framework, an operating system. The point of a CVE is that many people run the same code, so one identifier lets everyone track and patch the same bug.

Vibe-coded apps mostly don't fit that model. The vulnerability isn't in a shared library that thousands of people import; it's a configuration or code-pattern mistake in one person's bespoke app — Row Level Security left off, a key exposed in the browser, an endpoint missing an authorization check. There's no shared artifact to assign a CVE to. So when people picture a "vibe coding CVE list," what actually helps them is a catalog of the recurring vulnerability patterns, not a list of CVE numbers.

The patterns that belong on that list

If you built a practical "things AI builders keep getting wrong" list, it would look like the OWASP Top 10 seen through a vibe-coding lens:

• Broken access control / IDOR — data reachable by changing an ID. The single most common cause of large exposures.
• Missing Row Level Security — the public key can read the whole database. See what RLS is and why every Supabase app needs it.
• Exposed secrets — keys in the client bundle or a public repo. How to find them.
• Injection — user input concatenated into queries or commands.
• Security misconfiguration — missing headers, permissive CORS, leaky errors.

That's the real "list." It's short, it's stable, and it accounts for the overwhelming majority of incidents in AI-built apps.

What the Georgia Tech Vibe Security Radar is

The Georgia Tech Vibe Security Radar is referenced as an academic effort to track and categorize the security issues that appear in AI-generated ("vibe-coded") applications — the kind of structured, evolving catalog the space has been missing. Initiatives like this are valuable precisely because vibe-coding flaws don't get CVEs: someone has to name the patterns, measure how often they appear, and give builders a shared vocabulary. If you're citing it, check the project's official page for its current scope and findings first, since research efforts evolve and you want your reference to match what it actually says today.

Are vibe-coding vulnerabilities actually new?

The vulnerability typesaren't new — they're the same classic web flaws security people have catalogued for years. What's new is the frequency and the who. These flaws now appear far more often, in far more apps, built by people who can't necessarily read the code to spot them. That shift is why naming and tracking the patterns matters more than ever, even though the underlying bugs are old.

How to check your app against the list

You don't need CVE numbers to protect your app — you need to check it against the patterns above. A scanner encodes exactly these categories: it reads your live site (and, on a paid plan, your code) and flags exposed keys, missing RLS, missing headers, injection-prone queries, and misconfiguration, then explains each in plain English. Run Sayver's free website security scan to see which patterns apply to you, and use the pre-launch security checklist to close them before real users arrive.