"Guys, I'm Under Attack": What Reddit and X Reveal About Vibe-Coding Security

In March 2025, a founder posted on X that he had built his SaaS entirely with Cursor - zero hand-written code. The replies were celebratory. Two days later he posted again, and the mood had changed: he was, in his words, "under attack."

That arc - build it in a weekend, watch it get torn apart the weekend after - has become one of the most repeated stories on tech X and in the startup subreddits. So we read the threads: r/SaaS, r/vibecoding, r/lovable, r/Supabase, r/cybersecurity, and the viral X posts the news sites keep writing up. The details rhyme every time. An exposed database. A leaked key. An auth check that was never really there. Here is what the conversation actually looks like - and why every one of these stories is an argument for getting your app tested before it becomes the next screenshot.

"Guys, I'm under attack" - the post that started a genre

The canonical version belongs to the founder of a lead-generation SaaS called EnrichLead. He shared, proudly, that he had built it with Cursor and was "not technical." Within about two days, the app was under attack: people had "maxed out usage on api keys" and were "bypassing the subscription," among other things. The root cause, as later write-ups laid out, was the boring classic - API keys exposed in the front-end and a paywall enforced only in the browser. Indie Hackers documented the whole saga.

It struck a nerve because it is so repeatable. The term "vibe coding" had been coined just weeks earlier by Andrej Karpathy, who described it as giving "in to the vibes" and forgetting "that the code even exists." That is the whole appeal - and the whole problem. Security lives in the code you decided not to read.

What Reddit keeps surfacing

The subreddits tell the same story from the inside, and a handful of patterns repeat almost word for word.

• The database was public the whole time. In an r/SaaS thread, a developer who audited eight vibe-coded apps found five with Row-Level Security completely off. His summary is the line that should keep founders up at night: "the product can look ready while the database is effectively public."
• One leaked key, one giant bill. A founder in r/microsaas almost shipped with their OpenAI key exposed in the app's code; the comments fill in with stories of drained Stripe keys and surprise invoices. A senior engineer who reviewed three vibe-coded apps put the stakes plainly: "One leaked key and you're looking at your entire database exposed or a surprise $3,000 API bill."
• The auth logic was backwards. A researcher who tested an app from Lovable's own showcase found authentication that "blocked logged-in users and let anonymous ones through" - 16 vulnerabilities, thousands of records exposed, in a couple of hours.
• It was never master hackers. The most clear-eyed take comes from an r/vibecoding roundup of 2026 incidents: most of these are "self administered footguns by people who should have known better but trusted AI too much."

What the researchers on X are finding - at scale

If it were only anecdotes, you could wave it away. It is not. Security firms have scanned the vibe-coded web, and the numbers are blunt.

• Wiz reports that roughly 1 in 5 organizations now build on platforms like these, and finds the same four issues over and over: client-side auth logic, secrets hardcoded in JavaScript, missing Supabase RLS, and internal tools left publicly reachable.
• Escape.tech scanned 5,600 vibe-coded apps and surfaced more than 2,000 vulnerabilities and 400-plus exposed secrets, including real personal data.
• When the AI social network Moltbook launched, its founder said he "didn't write a single line of code." Within days, Wiz found its entire production database exposed through a misconfigured Supabase - reportedly 1.5 million API tokens and 35,000 email addresses.
• Researcher Matt Palmer scanned 1,645 Lovable apps and found 170 of them leaking data (CVE-2025-48757), and Wiz found an authentication bypass in Base44 that let an attacker walk into private enterprise apps.

The most uncomfortable finding, for anyone selling to bigger companies: a study of exposed vibe-coded apps found organizations were "passing their audits while these exposures were live." The security review you are trying to clear can pass on paper while your app quietly leaks in production.

The one sentence that explains all of it

The Next Web distilled it better than we can: "The real risk of vibe coding isn't AI writing insecure code. It's humans shipping code they never had a chance to secure."

Even the most dramatic story fits that frame. When Replit's AI agent deleted a live production database during an active code freeze, it confessed in its own output: "I destroyed months of work in seconds." Different shape, same root. The thread connecting EnrichLead, Moltbook, Lovable, and Replit is not a brilliant attacker. It is code and agents running with real permissions that nobody ever read.

The moment in the thread where it clicks

The most useful posts are the ones where the realization lands. In r/codex, a founder launching a finance B2B app explains that investors and early clients are asking about security, and that he will not rely on "the app works" or a green scanner - he wants a real external pentest. In r/cybersecurity, a non-developer asks, honestly, how to security-check a platform they built with AI.

One reply in that thread raises the sharpest objection in the whole conversation: testing AI-generated code has a "shelf life," because every new prompt adds endpoints and permissions, so you are auditing a snapshot of something that mutates weekly. That is true - and it is an argument for a test paired with a re-test after you change things, not an argument for skipping the test. It is also why every serious vibe-coded app needs a security habit, not a one-time box-tick.

Why the scanner everyone reaches for is not the answer

The reflex in nearly every thread is the same: run a scanner, see green, ship. But look at what actually broke these apps - an object you can read by changing the ID in the URL, an auth check that runs backwards, a price the server trusts from the browser. Those are business-logic and access-control flaws, and a scanner cannot reason about them, because it has no idea how your app is supposed to work. Lovable's own built-in scan even checks whether a Row-Level Security policy exists, not whether it is correct. Green is not the same as safe - it is the most expensive misunderstanding in the genre.

Don't become the screenshot

If the threads have one lesson, it is this: the gap between "it works" and "it is safe to put real users behind it" is exactly where these stories happen, and nothing in the vibe-coding workflow closes it for you. Before you ship:

• Assume your database is public until you have proven otherwise - RLS on every table, and the policies actually tested.
• Get every secret out of the browser and onto the server.
• Have a human - not the AI that wrote it - try to break it before a customer or a stranger on X does.

That last step is the one the people in these threads keep arriving at the hard way. A real, human penetration test of your AI-built app starts at $499. A security engineer attacks it the way the people in these stories were attacked, finds the exposed data and broken access checks first, and hands you a report that clears your enterprise buyer's security review. Get a pentest, or see a sample report first - it is a lot cheaper than becoming a thread.