The Tweet Heard Round the Internet

In March 2025, Leo Acevedo posted what he presumably thought would be an inspiring message to the tech entrepreneurship community. He'd built EnrichLead - a sales lead generation SaaS platform - entirely using Cursor AI. "Zero hand-written code," he announced proudly. The application was live. It had paying customers. It was proof that you didn't need to be a developer to build a software company. You just needed an AI coding assistant and enough confidence to ship whatever it produced.

The post went viral. Not in the way Acevedo intended.

Two days later, EnrichLead was under attack. Within a week, it was dead.

The Vulnerabilities

The security failures discovered in EnrichLead were not sophisticated exploits, zero-day vulnerabilities, or novel attack techniques. They were the kind of basic, foundational security oversights that any introductory web development course covers in the first week. A partial list:

API keys exposed in frontend code. The application's source code, visible to anyone who opened their browser's developer tools, contained hardcoded API keys. These keys provided direct access to the third-party services EnrichLead relied on - services that presumably had usage limits and billing implications. Exposing API keys in frontend code is roughly equivalent to taping your credit card to the outside of your front door.

No authentication. The application lacked meaningful authentication controls. Users - or, more accurately, anyone who navigated to the right URLs - could access functionality without proving they were authorized to do so. This isn't a subtle misconfiguration. This is the digital equivalent of building a store with no locks on any of the doors and then being surprised when people walk in and take things.

Open database. The database backing the application was accessible without credentials. No access controls. No authentication layer. No firewall rules restricting access. The data was just... there, available to anyone who knew where to look - or who spent thirty seconds looking.

No rate limiting. Without rate limiting, there was nothing preventing automated tools from making unlimited requests to the application's endpoints. This allowed attackers to cycle through API keys, extract data, and manipulate the system at machine speed.

No input validation. The application did not validate user input, opening the door to injection attacks and data manipulation. When the application accepts whatever input it receives without checking whether that input is sane, safe, or even expected, every input field becomes a potential attack vector.

The Cascade

The combination of these failures created what security professionals call a "cascade" - each vulnerability amplified the others. Exposed API keys allowed attackers to impersonate the application. No authentication meant they could do so without any challenge. An open database meant they could read and write whatever they wanted. No rate limiting meant they could do all of this at scale. No input validation meant they could inject malicious data into the system.

Attackers bypassed EnrichLead's subscription model entirely - why pay for access when the authentication system doesn't exist? They manipulated data in the database directly. They ran up usage on Acevedo's API keys, which presumably hit the billing limits on the services those keys connected to. Every paid API call Acevedo had budgeted for was now being consumed by unauthorized users doing whatever they wanted with his application.

The Fix That Wasn't

Acevedo's response to the security meltdown was to do what had gotten him there in the first place: he turned to Cursor AI for help. The result, as he described it publicly, was that "Cursor keeps breaking other parts of the code." This is the vibe coding paradox in its purest form. The AI that generated the insecure code was now being asked to fix the insecure code, except it didn't understand the code well enough to fix one thing without breaking something else. And Acevedo, by his own admission not a developer, couldn't manually intervene because he didn't write the code and didn't understand it well enough to debug it.

This is the trap that "zero hand-written code" sets. When everything works, the founder gets to take a victory lap. When something breaks, there's no one in the building who knows how the thing is put together. The AI generated the code. The AI doesn't remember the code. The human didn't read the code. And now the code is on fire and no one can find the extinguisher because the extinguisher was also generated by AI and it's actually a match.

The Shutdown

EnrichLead was permanently shut down within a week of the security failures being discovered. The application that had been celebrated as proof that AI could replace developers was instead proof that AI-generated code without human security review is a liability waiting to be triggered.

The timeline is worth emphasizing: the gap between "zero hand-written code" victory post and complete shutdown was approximately two days of normal operation followed by a week of cascading failure. The application's total useful lifespan, from the moment it attracted attention to the moment it ceased to exist, could be measured in hours.

The Founder's Next Move

In a detail that either speaks to admirable resilience or a learning curve that hasn't started curving yet, Acevedo reportedly pivoted to new vibe-coded projects after EnrichLead's shutdown. Kaspersky, the cybersecurity firm that covered the incident in their analysis of vibe coding security risks, noted this without editorial commentary, which is perhaps editorial commentary enough.

What This Demonstrates

The EnrichLead collapse is instructive not because the vulnerabilities were exotic - they were the opposite of exotic - but because it demonstrates the end-to-end lifecycle of a vibe-coded application built without security awareness.

Each of the individual failures (exposed keys, no auth, open database, no rate limiting, no validation) is well-understood and well-documented. Any security-aware developer would address them as a matter of course. Security scanning tools flag them automatically. Code review processes catch them. Even basic deployment checklists include them.

But vibe coding, by design, bypasses all of those safeguards. The developer (if we can use that term for someone writing zero code) doesn't review the code for security because they don't read the code at all. There's no code review process because there's no second developer. There's no security scanning because security scanning isn't part of the "describe what you want and ship it" workflow. There's no deployment checklist because the whole point was to skip the checklist.

EnrichLead shipped with every basic security control missing because the AI was optimizing for function - "make the sales lead platform work" - without any concept of security posture. The AI built what was asked for. It was never asked to build it securely, and it didn't volunteer.

The Pattern

The Vibe Graveyard has documented this pattern across multiple platforms and incidents. Base44 had authentication bypasses. Lovable shipped public storage buckets. The Tea dating app exposed government IDs. Moltbook leaked 1.5 million authentication tokens. EnrichLead adds to the collection by demonstrating what happens when every single basic security measure is absent simultaneously.

What makes EnrichLead's entry particularly memorable is the founder's public declaration of "zero hand-written code" in the same breath that the application was shipping without authentication. The combination of maximum confidence and minimum security review is the defining characteristic of vibe coding incidents, and EnrichLead may be its purest expression.