2,000+ Vulnerabilities Across 5,600 Vibe-Coded Apps: Your AI Speed Gain Is Someone Else's Attack Surface

General
1

I need to share something that has been keeping me up at night.

Last month, our AppSec team ran a comprehensive audit of every internal tool and prototype built using AI coding assistants over the past 6 months. We found 47 high-severity vulnerabilities across 12 applications—tools that engineering teams had already deployed to staging, and in 3 cases, production.

This is not a hypothetical. This is happening inside a Fortune 500 financial services company with a mature security program.

The Numbers Are Alarming

The industry data confirms what we found internally:

  • 2,000+ high-impact vulnerabilities found across 5,600 vibe-coded applications in a recent security audit (Palo Alto Unit 42)
  • 53% of AI-generated code contains security vulnerabilities (Autonoma research)
  • 175 instances of exposed personal data and 400+ exposed secrets across those same apps
  • Amazon’s March 2026 outage—caused by an AI-assisted code deployment—resulted in a 6-hour shutdown and an estimated 6.3 million lost orders

And these are just the ones we know about.

What’s Actually Going Wrong

After reviewing our audit findings with the AppSec team, the pattern is clear. AI agents generate code that works functionally but systematically skips:

  1. Input validation and sanitization — SQL injection and XSS vectors that any mid-level engineer would catch
  2. Authentication boundary enforcement — APIs that return data without checking whether the caller has authorization
  3. Secret management — Hardcoded API keys, database credentials in config files committed to repos
  4. Error handling that leaks information — Stack traces, internal paths, and system details exposed in error responses

The Moltbook incident in February was a wake-up call: a misconfigured Supabase database in their vibe-coded ecosystem exposed 1.5 million API keys and 35,000 user email addresses to the public internet. This was not a sophisticated attack. It was a misconfiguration that no human-written production code would have shipped with.

The Speed vs. Security Tension Is Real

Here is where it gets uncomfortable. My engineering teams are measurably faster with AI assistants. Feature delivery timelines have improved. Developer satisfaction is up. The business loves the velocity.

But every one of those speed gains came with security debt that nobody was tracking. We were essentially running two books: one that showed improved throughput metrics and one (that we only discovered through the audit) that showed an expanding attack surface.

In financial services, the regulatory implications are severe. We are talking about SOX compliance, PCI DSS, GLBA—frameworks that do not care whether the vulnerability was written by a human or an AI.

What We’re Doing About It

We have implemented three changes so far:

1. Mandatory security scanning in CI/CD for all AI-assisted code
Every PR now runs through SAST/DAST tooling with rules specifically tuned for common AI code patterns. This added ~4 minutes to our pipeline but catches roughly 70% of the issues.

2. “AI Code Review Checklist” for human reviewers
A focused checklist that hits the top 10 patterns we see AI agents miss. Input validation, auth boundaries, secret management, error handling, dependency pinning, CORS configuration, rate limiting, logging hygiene, data classification, and encryption at rest.

3. Quarterly AI code audits
Dedicated security review of all code produced with AI assistance in the prior quarter. This is expensive but necessary in our regulatory environment.

The Question I Cannot Answer

What I have not figured out is the cultural piece. How do you maintain the velocity benefits of AI coding while building a security-first mindset in teams that are increasingly relying on AI to write their code?

When an engineer uses Cursor or Claude Code to generate a feature, they are not thinking through the security implications the way they would if they wrote every line themselves. The cognitive engagement with the code is different. You are reviewing rather than creating, and that is a fundamentally different security posture.

For those of you managing engineering teams: How are you handling the security implications of AI-generated code? Are you seeing the same patterns? And for those in less-regulated industries—are you even tracking this, or is it a problem you will deal with later?

I suspect a lot of teams are sitting on a security debt iceberg and do not know it yet.

2

Luis, this post articulates something I have been trying to explain to my board for three months. Thank you for putting hard numbers to it.

I want to push back on one framing though: this is not primarily a tooling problem. It is an organizational design problem.

At my company, we went through a similar awakening. Our security team discovered that 40% of the vulnerabilities in our last pentest originated from AI-assisted code. But here is the part that made me rethink everything: the same engineers who wrote secure code manually were producing insecure code with AI assistance.

These were not junior engineers. These were staff-level people with 10+ years of experience. The issue was not skill—it was cognitive mode.

The Review vs. Create Gap

When you write code from scratch, security thinking is embedded in the creation process. You think about edge cases as you design. When you review AI-generated code, you are pattern-matching against what looks correct. And AI-generated code looks correct. It passes the vibes check. That is literally why it is called vibe coding.

This is the same reason code review alone has never been sufficient for security—it is why we have dedicated security testing. But we somehow convinced ourselves that human review of AI code was enough.

What I Changed

I restructured our engineering org around this reality:

  1. Security engineers embedded in every team, not siloed. Not as gatekeepers, but as pair reviewers specifically for AI-generated code.
  2. “Security intent” as a required field in PRs. Every PR that includes AI-generated code must document what security properties the author verified. Not a checklist—a narrative explanation.
  3. AI code provenance tracking. We tag every file that was substantially AI-generated. This is not about blame—it is about knowing where to focus audit attention.

The provenance tracking was controversial. Engineers felt like they were being surveilled. But framing it as “audit efficiency” rather than “trust deficit” helped. In regulated industries, you need to know the lineage of your code the same way you need to know the lineage of your data.

The uncomfortable truth: AI coding assistants have made the CTO’s job harder, not easier. The velocity gains are real, but so is the risk surface. And the board does not want to hear “we shipped faster but with more vulnerabilities.”

3

OK I am going to be the person who says the slightly uncomfortable thing here.

Luis, your data is alarming and I do not question it. Michelle, your org restructuring makes total sense for a SaaS company at scale. But I want to talk about the other side of this equation that nobody in this thread has mentioned yet.

Not Everyone Is Building Financial Services Software

I run a design systems team. I also build side projects. Last month I shipped a portfolio site, an internal design token preview tool, and a client feedback widget—all with heavy AI assistance. All three are live in production.

Did I run a security audit on any of them? No. Would a security audit find issues? Probably. Does it matter? For those specific use cases, honestly, probably not.

The 53% vulnerability stat is real, but context matters enormously. A hardcoded API key in an internal design preview tool that sits behind our VPN is a very different risk than a hardcoded API key in a customer-facing banking application.

The Risk of Overreacting

What worries me about this conversation is that engineering leadership will use data like this to clamp down on AI tools entirely—adding so many gates and checklists that we lose the very productivity gains that make these tools transformative.

I have seen this movie before. It happened with open source adoption. It happened with cloud migration. Leadership gets scared by a high-profile incident, institutes heavyweight governance, and the result is that legitimate innovation gets strangled while people who want to move fast just work around the rules anyway.

If your response to “53% of AI code has vulnerabilities” is to add 4 minutes to every CI pipeline plus mandatory security narratives plus quarterly audits—you have added significant friction. For financial services? Justified. For a 15-person startup trying to find product-market fit? That is a death sentence.

What Actually Works for Smaller Teams

Here is what we do instead, and it costs basically nothing:

  1. Threat model by deployment context. Internal tools get lighter review than customer-facing ones. Not everything needs the same security posture.
  2. CLAUDE.md and Cursor rules files with security constraints. We bake security requirements into the AI’s system prompts. “Never hardcode secrets. Always validate input. Use parameterized queries.” It does not catch everything, but it catches the dumb stuff.
  3. Design reviews that include security surface. When we review designs, we explicitly ask “what data touches this?” before any code gets written. Shifting security left—before the AI even generates the code.

I guess my point is: the answer is not one-size-fits-all, and I worry that threads like this (with genuinely scary data) lead to policies designed for the most risk-averse environments being applied everywhere.

4

This thread is fascinating and I want to bring the product perspective because I think it is missing from this conversation.

The Business Case Nobody Is Making

Luis, when you describe “running two books”—one showing improved throughput and one showing expanding attack surface—that framing should terrify every product leader reading this. Because here is what happens when the attack surface book comes due:

A single data breach costs an average of $4.88 million (IBM 2024 Cost of a Data Breach). For financial services, it is higher. The velocity gains from AI coding assistants—which might save your team, generously, $500K-$1M per year in engineering time—evaporate the moment you have a security incident.

This is not a close call. The expected value math does not work if you are not investing in security alongside velocity.

But Maya Has a Point

Maya, your push-back about context-dependent risk is exactly right from a product strategy perspective. And this is actually how we think about it in product management: not all features have the same risk profile, and not all code paths deserve the same security investment.

At my company we implemented what we call a “security tier” system for product features:

  • Tier 1 (Crown Jewels): Anything touching payments, PII, or auth. Zero AI-generated code ships without dedicated security review. Period.
  • Tier 2 (Business Logic): Core product features. Standard security scanning in CI, AI code review checklist, but no dedicated security review.
  • Tier 3 (Presentation/Internal): Admin dashboards, internal tools, marketing pages. Lightweight scanning only. Move fast.

This lets us capture 80% of the velocity benefit of AI coding on the 60% of our codebase that is Tier 3, while maintaining rigorous security on the 15% that is Tier 1. The engineering team was skeptical at first—they said it creates a two-class system. And it does. That is the point. Not all code is equal.

The Feature I Want That Does Not Exist Yet

What I really want as a product leader is a way to express security requirements as constraints in the AI prompt itself, tied to the feature spec. Something like:

“This feature handles payment card data. It MUST comply with PCI DSS requirements. Generate code with: parameterized queries only, no logging of card numbers, encrypted at rest, audit trail for all access.”

Michelle’s “security intent” field in PRs is the manual version of this. But we should be building toward a world where the AI itself understands the compliance context of what it is generating. The fact that we are asking humans to catch what AI missed feels like a transitional pattern, not the end state.

The Real Question for Leadership

The question for everyone in this thread is not “how do we make AI-generated code more secure?” It is: “how do we build security awareness into the AI-assisted development workflow so seamlessly that engineers do not experience it as friction?”

Because if security feels like friction, people will route around it. That is not a technology problem—it is a product design problem. And it is solvable.

5

I have been reading this thread all morning and everyone has brought something valuable, so I want to try to synthesize where I think this conversation actually lands for engineering leaders who need to make decisions next week, not next year.

The Talent Dimension Nobody Has Mentioned

There is a workforce angle to the vibe coding security crisis that concerns me deeply. We talk about AI-generated code having vulnerabilities. But who is supposed to catch them?

Consider the current market reality:

  • The tech unemployment rate is 5.8%—the highest since the dot-com bust
  • Early-career engineering roles are contracting because AI handles foundational tasks
  • The engineers being let go are disproportionately the mid-level engineers who would traditionally be your security-aware code reviewers

We are simultaneously making code review more important (because AI code needs more scrutiny) and reducing the population of engineers who are experienced enough to do that review effectively. This is a structural problem that no CI/CD pipeline can solve.

At my EdTech startup, I am scaling from 25 to 80+ engineers. Over half my recent hires have fewer than 3 years of experience. They are brilliant with AI tools—they ship features fast. But when I asked my security lead to assess their ability to review AI-generated code for vulnerabilities, her answer was sobering: “They cannot catch what they have never had to write.”

Where I Partially Disagree with Maya

Maya, I appreciate the context-dependent argument and I use a similar tiering system. But I want to push back gently on one thing: the “internal tools behind the VPN” framing underestimates lateral movement risk.

Every security incident I have investigated in the last two years started with a compromised internal tool. The internal design preview tool with the hardcoded API key becomes the beachhead for accessing the production database. Shadow IT and internal tool sprawl are explicitly called out in the Unit 42 research Luis cited.

That said, your point about proportional response is well taken. We should not treat a marketing page the same as a payments service.

What I Am Actually Implementing

David’s security tier framework resonated with me, so here is my variant adapted for a high-growth startup:

Security-Aware AI Development Policy (one page, not a binder):

  1. Every team has a “security champion”—not a dedicated security engineer (we cannot afford that), but a senior engineer with security training who reviews all Tier 1 PRs and spot-checks Tier 2/3.
  2. AI security training is part of onboarding. Every new engineer completes a 2-hour module on the top 10 AI code security patterns before they get access to production repos. We built this with real examples from our own codebase.
  3. Monthly “security bug bash” for AI-generated code. One afternoon per month, the team looks at recently shipped AI-generated code specifically for security issues. We have found 6 significant vulnerabilities in 3 months through this practice alone.
  4. CLAUDE.md files are first-class engineering artifacts. They get reviewed in PRs just like code. Security constraints, coding standards, and compliance requirements live there and are version-controlled.

The Actual Answer

I think Luis asked the right question: how do you maintain velocity while building security awareness? And I think the answer is emerging from this thread:

You do not bolt security onto AI-assisted development. You redesign the development workflow so that security is an input to the AI, not just a check on its output.

David’s vision of expressing security requirements as AI constraints, Maya’s point about CLAUDE.md files with security rules, Michelle’s security intent documentation, and Luis’s AI-specific review checklists—these are all pieces of the same puzzle. The teams that figure out how to make security a generative input rather than a reactive gate will win both the velocity and the security game.

Thanks for starting this thread, Luis. This is exactly the kind of conversation we need to be having openly rather than pretending we have it figured out.