Triaging Vulnerabilities in Vibe-Coded Projects: Severity, Exploitability, Impact

You just told an AI to build a dashboard. It spat out working code in minutes. You clicked "deploy," and it looked great. But here is the uncomfortable truth: your new app might be leaking user data right now, and you didn't even write a single line of code to cause it. This isn't hypothetical. Research from Escape.tech found over 2,000 verified vulnerabilities in vibe-coded applications. That’s not a rounding error; that’s a systemic failure mode.

Vibe coding is a development paradigm where human engineers instruct large language model (LLM) agents to complete complex coding tasks through high-level instructions rather than detailed specifications. While it accelerates velocity, it introduces unique security challenges. Traditional triage methods assume a developer wrote the bug with intent or negligence. In vibe coding, the "developer" is a probabilistic engine trained on billions of lines of code, many of which are insecure. To survive this shift, you need a new way to judge risk. You can’t just look at severity scores. You have to look at how easily an attacker exploits the specific quirks of AI-generated logic.

The Illusion of Functional Correctness

Why do so many vibe-coded apps fail security checks? Because LLMs are optimized for functionality, not safety. They want the code to run. They don’t care if it runs securely. The SusVibes benchmark, published in late 2025, provides hard evidence. It tested frontier LLMs against 200 tasks spanning 77 different CWE types. The result? These models failed over 80% of security tests while passing more than 50% of functional tests.

This gap is dangerous. If your code works, you assume it’s safe. But in vibe coding, "working" often means "bypassing validation." For example, an LLM might generate a SQL query that concatenates strings directly into the command. It works perfectly when you test it with clean data. It breaks catastrophically when an attacker injects malicious syntax. Databricks research confirmed this, showing that approximately 45% of AI-generated code fails security tests, introducing classic OWASP Top 10 issues like SQL injection and XSS. The model didn't make a typo; it replicated a pattern it saw frequently in its training data, unaware that those patterns were deprecated for good reason.

Redefining Severity for AI-Generated Code

In traditional software, we use CVSS scores to rank bugs. A 9.8 is critical; a 6.5 is medium. But CVSS doesn't account for the propagation speed of vibe-coded flaws. When an LLM generates a component, it often copies insecure patterns across multiple files. A single bad authentication check in one module might be replicated in ten others because the model treats them as similar contexts.

ReversingLabs suggests modifying the DREAD model to fit this reality. Instead of treating all factors equally, they weight "Exposure" heavily-giving it a 40% weight compared to the standard 20%. Why? Because vibe-coded projects deploy fast. A vulnerability exposed in production is reachable by attackers almost immediately. Damage gets 30%, Reproducibility 15%, Exploitability 10%, and Affected Users 5%. This hierarchy reflects the reality that in AI-assisted dev, breadth of exposure is scarier than depth of impact. If a secret key is hardcoded in three places, it’s worse than a complex buffer overflow in one place, simply because fixing the secret requires rotating keys across multiple services instantly.

Assessing Exploitability: The Effort vs. Reward Matrix

Not all bugs are equal. Some require a PhD in binary exploitation to trigger. Others require nothing but a browser address bar. Vidoc Security Lab categorized vibe-coding risks by exploitability vectors, providing a clear guide on what to fix first. Their data shows that hardcoded secrets are exploitable in 100% of cases with trivial effort. Broken authorization follows at 87% with moderate effort. Insecure deserialization sits at 63% but requires advanced effort.

Look at the table above. Hardcoded secrets are the low-hanging fruit. An LLM will happily paste an API key directly into a JavaScript file because it saw that pattern in tutorials. It’s trivial for an attacker to find via GitHub search or source map inspection. Therefore, despite potentially lower individual impact than a complex race condition, secrets demand immediate triage. You cannot afford to leave these in production for even a day.

The Propagation Problem and Reachability

Traditional scanners flag every instance of a bug. In vibe-coded projects, this creates noise. If the LLM copied a vulnerable function five times, do you have five bugs or one? You have one root cause with five instances. Triage must focus on reachability. Does the vulnerable code path actually execute in production?

Escape.tech’s methodology highlights this. They start with asset ingestion-mapping hosts, APIs, and schemas-then perform reachability checks. They replay requests without tokens or with modified headers to confirm if missing authentication actually blocks access. Only high-confidence findings remain. This conservative approach saves time. In a vibe-coded environment, you might see hundreds of alerts. Most are false positives or unreachable dead code generated by the model’s tendency to include unused libraries. Filter by reachability first. If the endpoint isn’t called, the bug isn’t urgent. If it is called, and it touches PII, it’s critical.

Implementing Structured Reflection in the Pipeline

How do you catch these issues before deployment? Manual review is too slow. Automated scanning alone misses context. The solution lies in structured reflection. Databricks demonstrated that feeding the LLM’s output back into the model with specific security prompts reduced vulnerability rates by 57%. This isn’t magic; it’s forcing the model to critique its own work against a checklist.

Aikido.dev formalizes this into a three-level checklist. Level 1 involves basic CI/CD integration with SAST tools like SonarQube, which detects 85% of code quality issues. Level 2 mandates AI self-review. You explicitly prompt the LLM: "Identify hardcoded secrets," "Verify data accessibility," and "Scan for vulnerable dependencies." Level 3 adds organizational policy, such as automatic secret revocation SLAs.

Here is a practical workflow for triage:

• Step 1: Static Scan. Run SAST tools to identify obvious syntax and pattern errors.
• Step 2: AI Self-Reflection. Prompt the LLM to review its own code for OWASP Top 10 risks. Ask specifically about input validation and auth checks.
• Step 3: Dynamic Testing. Use DAST tools like OWASP ZAP to test running endpoints for runtime behaviors.
• Step 4: Human Context Check. A human engineer reviews only the flagged items. Focus on business logic flaws that AI cannot understand, such as "should User A really be able to delete User B's record?"

This hybrid approach catches 91% of vulnerabilities that either method would miss alone, according to IBM Research. It balances speed with accuracy. You aren't trying to achieve zero defects; you're trying to eliminate the easy wins for attackers.

Impact Assessment: Beyond Data Breach

What happens when a vibe-coded app fails? The impact isn't just data loss. It’s reputational damage and operational drag. Nucamp’s analysis recommends treating AI output like a junior developer’s draft. Would you let a junior dev push code to production without review? No. So why treat the LLM differently?

Consider the case of marketing agencies using platforms like Duda.co. They documented cases where vibe-coded websites exposed client data due to insufficient input validation. The impact wasn't just a breach; it was a halt to campaign launches while legal teams scrambled. In vibe coding, the cost of remediation spikes after deployment because the original context is lost. Who wrote the prompt? What did the AI interpret? Reconstructing this logic takes longer than writing the code initially.

Therefore, impact assessment must include "remediation friction." If a bug is easy to spot but hard to fix because it’s buried in generated boilerplate, its priority rises. Tools like GitGuardian help here by monitoring SBOM drift with 99.2% accuracy, ensuring that dependency updates don’t silently break security assumptions made by the LLM.

The Future of Triage: AI-Assisted Prioritization

We are moving toward AI-assisted triage. Google Cloud’s 2025 Security Command Center update introduced vibe-coding-specific prioritization, reducing false positives by 42% through contextual understanding of AI-generated patterns. This means the system knows that certain verbose, repetitive code structures are typical of LLMs and shouldn't always trigger high-severity alerts unless they involve sensitive operations.

However, human expertise remains irreplaceable. Researchers found that when LLMs tried to fix vulnerabilities, they introduced new issues in 68% of cases. The model lacks true security context awareness. It sees syntax, not semantics. As a developer, your job shifts from writing code to validating security posture. You become the gatekeeper. Your intuition about business logic, combined with automated tools, forms the final defense layer.