Triaging Vulnerabilities in Vibe-Coded Projects: Severity, Exploitability, Impact
Sep, 10 2026
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.
| Vulnerability Type | Exploitability Rate | Effort Required | CVSS Rating | Triage Priority |
|---|---|---|---|---|
| Hardcoded Secrets | 100% | Trivial | 9.8 (Critical) | Immediate |
| Broken Authorization | 87% | Moderate | 8.2 (High) | High |
| Insecure Deserialization | 63% | Advanced | 6.5 (Medium) | Medium |
| Insecure HTTP Connections | Variable | Low | High | High |
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.
Why does vibe coding introduce more security vulnerabilities than manual coding?
Vibe coding relies on LLMs trained on vast repositories containing insecure patterns. These models prioritize functional correctness over security constraints. Consequently, they often replicate deprecated practices like string concatenation in SQL queries or hardcoded secrets, leading to higher rates of OWASP Top 10 vulnerabilities despite passing functional tests.
What is the most critical vulnerability type to triage first in vibe-coded projects?
Hardcoded secrets should be triaged first. According to Vidoc Security Lab, they are exploitable in 100% of cases with trivial effort. Attackers can easily scan source maps or public repositories to extract these keys, making them the highest-priority risk regardless of other complexity factors.
Can automated tools fully replace human review for vibe-coded security?
No. While automated tools like SAST and DAST detect technical flaws, they lack business context. Humans must verify logical authorization rules and ensure that generated code aligns with specific application requirements. IBM Research indicates that combining automated scanning with human-led structured reflection catches significantly more vulnerabilities than either method alone.
How does the SusVibes benchmark measure AI security performance?
The SusVibes benchmark tests frontier LLMs against 200 tasks spanning 77 CWE types drawn from open-source projects. It reveals that while models pass over 50% of functional tests, they fail over 80% of security tests, highlighting a significant gap between code functionality and security robustness in AI-generated code.
What is 'structured reflection' in the context of vibe coding security?
Structured reflection involves feeding the LLM's generated code back into the model with specific security prompts, asking it to identify potential flaws like hardcoded secrets or missing input validation. This technique has been shown to reduce vulnerability rates by up to 57% by leveraging the model's ability to critique its own output.
Jacob Baby Official
September 11, 2026 AT 23:41This is absolute garbage. You people are so busy patting yourselves on the back for using an LLM to write code that you forgot what security actually means. It's not about "triage," it's about competence. If you can't write a secure query by hand, you don't deserve to deploy anything. This entire industry is collapsing under the weight of lazy developers who think "vibe coding" is a substitute for understanding how computers work. The fact that 2,000 vulnerabilities were found isn't a systemic failure mode; it's proof that humans have stopped caring. We are drowning in technical debt created by machines that don't even know they're lying to us. Wake up.
john randall
September 12, 2026 AT 17:42Interesting read. The shift from intent-based bugs to probabilistic ones is definitely something we haven't fully grappled with yet.
Jeff Falcon
September 13, 2026 AT 11:22I completely agree with the point about exposure being weighted more heavily than impact in this specific context because, honestly, if a secret key is leaked in three places, the blast radius is immediate and widespread, whereas a complex logic bug might take weeks to be discovered by a determined attacker, so the risk profile changes entirely when you consider the speed at which these vibe-coded apps hit production environments without proper scrutiny or peer review processes that used to act as a safety net before deployment pipelines became automated black boxes.
Alyson Karson
September 14, 2026 AT 16:27YES! Finally someone says it!! We need to stop treating AI output like gospel and start treating it like a junior dev who hasn't had their coffee yet!!! Hardcoded secrets are the worst and I see them everywhere now because the model just copies tutorials blindly!!! Fix your CI/CD pipelines NOW or get ready for a breach!!!
Chris Neal
September 15, 2026 AT 02:37The SusVibes benchmark data is crucial here. Most people ignore that functional correctness does not imply security robustness. An LLM optimizes for passing tests, not for preventing exploits. That distinction is fundamental. Also, the propagation problem is underestimated. One bad pattern replicated across ten files isn't ten bugs; it's one architectural flaw multiplied by convenience.
Vishnu Vardhan Reddy M S
September 15, 2026 AT 03:25Oh wow, another article telling us that AI is going to ruin everything unless we do exactly what the consultants say. Groundbreaking stuff. But seriously, the point about remediation friction is spot on. Trying to debug generated boilerplate is like trying to find a needle in a haystack made of other needles. Good luck reconstructing the prompt context six months later when the app breaks.
Kyle Ware
September 16, 2026 AT 08:42Good breakdown. The hybrid approach mentioned near the end is the only viable path forward. Pure automation misses context, pure human review is too slow for this velocity. Integrating structured reflection into the pipeline is key. Start small with SAST then add the AI self-review step. Don't try to boil the ocean on day one.
Onyinyechi Nwosu
September 17, 2026 AT 10:14this makes sense especially the part about hardcoded secrets being trivial to exploit i keep seeing api keys in js files and its scary how easy it is to miss them during a quick review
Iva Grekova
September 18, 2026 AT 13:51I really appreciate the focus on reachability. In my experience, many alerts are false positives because the code paths aren't even active. Filtering by actual execution flow saves so much time and helps teams focus on what truly matters rather than chasing ghosts in the machine.
Chandan Singh
September 19, 2026 AT 13:46While the points regarding CVSS limitations are valid, one must consider that standardizing new metrics takes years. Until DREAD modifications become industry standard, we are stuck with legacy scoring. However, the emphasis on 'remediation friction' is technically sound as it introduces a temporal dimension to severity assessment which is often overlooked in static analysis tools today.