All articles

Hacking a "Vibe-coded" App in 15 Minutes: A Real Case Study

Hacking a "Vibe-coded" App in 15 Minutes: A Real Case Study

A step-by-step breakdown of how an attacker can find an exposed database port and a .env file in AI-generated code. Demonstrating the critical need for external DAST scanning.

March 28, 2026VibeWShield Team2 min read

Developers are increasingly using Cursor, Lovable, Bolt, and other AI tools to build applications at incredible speed. This approach, known as "vibe-coding," allows you to write and deploy features in hours instead of weeks.

The problem? Neural networks are great at writing features but terrible at configuring infrastructure security.

In this breakdown, we'll look at a real, anonymized case: how a fresh vibe-coded application launched into production by an indie hacker was compromised (as part of a white-hat test) in just 15 minutes. And more importantly—how VibeWShield would have found these vulnerabilities in 60 seconds.

Mistake #1: Blindly Trusting AI Docker Configs

Most developers ask AI to generate a docker-compose.yml and deploy it straight to a VPS. In our case, the developer asked for a Next.js + PostgreSQL + Redis stack.

The AI provided a standard config:

services:
  postgres:
    image: postgres:15
    ports:
      - "5432:5432"
    environment:
      POSTGRES_PASSWORD: mysecretpassword

Notice the problem? The ports: - "5432:5432" directive binds the database port to all network interfaces on the server (0.0.0.0). Any public scanner on the internet (like Shodan) will detect the exposed database.

It took the attacker 2 minutes to run an Nmap scan and brute-force the default password mysecretpassword, which the developer left "just for testing."

Mistake #2: Storing .env in a Public Directory or Build

When AI generates a Dockerfile for Next.js, it often writes something like:

COPY . .
RUN npm run build

Sometimes developers accidentally carry the .env file over into the final container or, worse, into the public/ folder if the server was misconfigured (or if a static hosting provider with direct file access was used).

In our case, a directory scanner brute-forced common paths in 3 minutes and found https://target-app.com/.env, gaining access to AWS keys, a Stripe Secret API Key, and an OPENAI_API_KEY.

How to Protect Yourself? (Why SAST Doesn't Work)

If you run such code through a Static Application Security Testing (SAST) tool in your IDE, it might flag hardcoded warnings, but it doesn't know how the application is actually deployed in the cloud.

This is where DAST (Dynamic Application Security Testing) comes into play.

The VibeWShield scanner works from the outside—it attacks your public application exactly the way hackers do:

  1. It scans open ports (Database Exposure) on your IP, immediately highlighting the exposed 5432.
  2. It fuzzes leftover configuration files (Info Disclosure) and finds publicly accessible backups or .env files.
  3. It analyzes client-side JS bundles for hardcoded (leaked) API keys.

Conclusion

Vibe-coding is the future. Release speed dictates everything today. But don't let speed turn into a fatal breach on launch day.

Before releasing—simply paste your URL into VibeWShield. The scan takes 1-3 minutes. We'll find the holes, and you'll get ready-to-use "AI Fix Prompts" that you can paste right back into Cursor for instant remediation.

Ship fast. Stay shielded.

Free security scan

Test your app for these vulnerabilities

VibeWShield automatically scans for everything covered in this article and more — 18 security checks in under 3 minutes.

Scan your app free