Vibe coding: why 45% of AI code is vulnerable

4.75 million records leaked in one day

January 2025. Moltbook goes viral. A social network where AI agents talk to each other. Within a week, 1.5 million “agents” registered. The founder proudly claims: “I didn’t write a single line of code.”

That was true. And that was exactly the problem.

Security researchers at Wiz found an open door within minutes. The Supabase API key was just sitting in the JavaScript. No Row Level Security configured. Result: full access to the database. Read and write.

What was leaked:

• 4.75 million database records
• 1.5 million API tokens
• 35,000 email addresses
• OpenAI API keys in plaintext messages

The fix took less than 4 hours. But the damage was done.

Disclosure timeline:

• January 31, 2026, 21:48 UTC, Wiz Research contacts Moltbook
• February 1, 2026, 01:00 UTC, all tables secured

Three hours. That’s how fast it can be fixed. The question is why it could happen at all.

Interesting detail: while Moltbook claimed to have 1.5 million “agents,” the database showed only 17,000 human owners. A ratio of 88:1. The platform was largely bots talking to bots, but the leaked API keys and email addresses were real.

What is vibe coding, really?

Vibe coding is building software through AI prompts without writing or understanding any code yourself. You describe what you want, the AI generates it, you deploy it. Done. Within an hour you have a working product. Within a day your database could be leaked.

It works. It’s fast. And it’s dangerous if you don’t know what you’re doing.

We use it ourselves too. When building ibgids.nl and certificeerwijzer.nl we had a lot of code generated by Claude and Copilot. In the first weeks we found multiple hardcoded API keys in our own AI-generated code. Gitleaks caught them before they ended up in Git. The difference: we review everything. We understand what the code does. We check security settings.

This is, by the way, not the only AI-related security risk. 12% of AI skills turn out to be malicious, designed to steal data. The problem is broader than just code.

That last part often doesn’t happen.

The numbers aren’t great

Veracode researched AI-generated code for security in 2025:

That’s not a little bad. That’s almost half of all code.

And it gets worse. AI tools generate code 4x faster than humans. But vulnerabilities also pile up 4x faster. One in five organizations has already had a breach directly linkable to AI-generated code.

The five biggest risks

1. Hardcoded credentials

The Moltbook problem. API keys in the frontend JavaScript. Passwords in config files. Tokens that are never rotated.

AI tools do this 2x as often as human developers. Not because the AI is dumb, but because the AI optimizes for “it works”, not for “it is secure”.

What you do:

• Use environment variables, never hardcoded values
• Set up Gitleaks as a pre-commit hook (free, 2 hours to set up)
• Scan your repository for leaked secrets with TruffleHog

2. Database misconfigurations

83% of exposed Supabase databases have no Row Level Security. The database is just open.

Supabase is designed to work with a public key. That’s secure, but only if you configure RLS. Without RLS, anyone can read and write everything.

Firebase has the same problem. “Test mode” often stays on. ~150 of the ~200 audited apps had permissive configs.

What you do:

• Enable Row Level Security on every table. No exceptions.
• Create policies that determine who may do what
• Check that you’re using your anon key (not the service key) in the frontend

A similar principle applies to other infrastructure. See also how to install local LLMs securely, 175,000 Ollama servers are open due to the same mistake: wrong configuration.

3. Slopsquatting: fake packages with malware

This is new. AI hallucinates packages that don’t exist. 20% of the packages AI recommends don’t exist.

Attackers have caught on. They register those non-existent package names and fill them with malware. You install it unknowingly.

Example: AI suggests requests-proxy. Doesn’t exist. Attacker registers it on PyPI. Developer installs it. Malware runs.

In 2025: 440,000 hallucinated dependencies found in 2.23 million examined package references. Malicious uploads to open-source repos +156%.

What you do:

• Check whether packages exist: npm info package-name or pip show package-name
• View the package on npm/PyPI: <10,000 downloads and <6 months old = extra careful
• Use OWASP Dependency-Track for SBOM management (free)
• Look at download counts and maintenance status

4. Missing input validation

AI optimizes for the “happy path”. User fills in the form correctly, data is saved, done.

But what if someone tries SQL injection? Or pastes a script into an input field? AI doesn’t think about that.

86% of AI-generated code fails on XSS prevention. SQL injection remains a top problem.

What you do:

• Validate all input server-side (not just in the UI)
• Use parameterized queries, never string concatenation
• Run Semgrep in your CI/CD pipeline (free tier available)

5. Too much trust in AI output

This is perhaps the biggest problem. AI code looks good. It works. It has comments. It seems professional.

But it lacks context. The AI doesn’t know that you need authentication. Or that that function can also be called via the API, not just via the UI.

What you do:

• Treat AI code like code from an external source
• Review on behavior, not on syntax
• Ask: “What happens if someone bypasses the UI?”

Five measures you can take today

This costs you a day. Maybe two. All free.

A minimum AI governance policy

This doesn’t have to be complicated:

Approved tools: ChatGPT Plus, Claude Pro, GitHub Copilot

Forbidden data in AI tools:

• Customer data
• Passwords and API keys
• Financial records

Mandatory procedures:

• All AI-generated production code is reviewed
• Dependencies are checked before they’re installed
• When in doubt: treat data as sensitive

That’s it. One page. Communicate it to your team.

The roadmap for the coming month

Week 1-2: Basics

• Write and share the governance policy
• Install Gitleaks pre-commit hooks
• Audit all Supabase/Firebase configurations

Week 3-4: Automation

• Set up Semgrep in your CI/CD pipeline
• Create a code review checklist for AI code
• Enable security scanning in GitHub/GitLab

Month 2+: Further development

• Implement Dependency-Track for SBOM
• Appoint a security champion (tip: this also helps with audits, auditors increasingly ask about AI governance)
• Plan the first security awareness session

After 4 weeks you have the basics in place. After 8 weeks you’re audit-ready.

What we learn from this

Vibe coding is not the problem. It is a tool. A powerful tool that lets you build 4x faster.

The problem is vibe coding without thinking about security. Without reviewing what the AI makes. Without checking whether your database settings are correct.

Moltbook hadn’t written any lines of code. But they also hadn’t checked any security settings.

We build with AI too. A lot, in fact. But we review everything. We understand what the code does. We check the configurations.

That is the difference between building fast and failing fast. There is a whole spectrum between vibe coding and responsible building with AI. We describe the four levels of AI coding, from blind acceptance to maximum control.

Want to know how to deploy AI securely and structurally in your business? Read our 7 steps to becoming AI-native, including how to set up guardrails without bureaucracy.

Need help?

Want to know whether your AI-generated code is secure? We do a quickscan of your Supabase/Firebase configuration and look at your biggest risks. Takes 30 minutes, no obligations.

Schedule a call →

Sources: Wiz Research, Hacking Moltbook, Infosecurity Magazine, Axios, Moltbook security threats, Veracode GenAI Security Report 2025, OWASP Top 10 for LLM Applications 2025