About the Author
This article was written by Ahmar Imam with over a decade of combined experience in threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert
What is vibe coding security?
Vibe coding security is the practice of finding and fixing vulnerabilities in applications built primarily through natural-language prompts to AI coding tools, rather than through traditional line-by-line development. The term borrows from “vibe coding”, writing software by describing what you want and letting an AI assistant generate the implementation, a workflow that has moved from novelty to mainstream practice in a little over a year.
The problem this category exists to solve is simple to state: AI coding tools are extremely good at making code that runs, and inconsistent at making code that’s safe. A feature can look complete, pass a manual click-through, and still ship with an open authentication bypass, a hardcoded API key, or an unvalidated request path that lets an attacker reach internal infrastructure. Vibe coding security scanners are built to catch exactly that gap, the space between “it works” and “it’s safe to expose to the internet.”
Why AI-generated code needs a dedicated scanner
The scale of the problem
The numbers here are large enough that they’ve moved from anecdote to formally tracked data.
Independent testing has repeatedly found that AI-generated code fails basic security review at a high and fairly consistent rate. In controlled testing, roughly 45% of AI-generated code samples contained at least one OWASP Top 10 vulnerability when reviewed without human oversight. Separate research out of Georgetown’s Center for Security and Emerging Technology found cross-site scripting (XSS) vulnerabilities in 86% of AI-generated code samples across five major language models.
The trend is also accelerating, not stabilizing. Georgia Tech’s Vibe Security Radar, a project that traces confirmed CVE entries back to the AI tool that generated the vulnerable code, recorded 6 new CVEs directly attributed to AI-generated code in January 2026, 15 in February, and 35 in March. That’s roughly a sixfold increase in new confirmed vulnerabilities in a single quarter, and of the 74 cases confirmed through that period, more attributions traced back to Claude Code than to any other tool, with GitHub Copilot and a handful of autonomous coding agents accounting for the rest.
Secrets exposure follows a similar pattern. AI-assisted commits expose hardcoded secrets at roughly twice the rate of human-written commits, about 3.2% versus 1.5%. At the volume most teams are now shipping AI-generated code, that difference compounds fast.
Why traditional SAST tools miss AI-specific issues
Most static analysis tools were built to catch patterns in code written by humans, who tend to make a narrower and more predictable range of mistakes. AI coding tools introduce a different failure mode: they’re frequently correct about syntax and logic while being systematically wrong about security defaults, because the model isn’t reasoning about your specific threat model, it’s producing the statistically likely completion for the prompt it was given.
That shows up in framework-specific ways that generic scanners often don’t check for at all. A well-known example: applications generated with tools like Lovable have shipped with publicly exposed databases because the generated code never explicitly configured Supabase Row Level Security policies, a control that has to be turned on deliberately, and one that a general-purpose SAST tool has no reason to specifically look for unless it’s been tuned for AI-generated output.
A scanner built for vibe coding security checks for this class of issue by design: missing framework-level access controls, insecure defaults baked in during code generation, and the specific vulnerability patterns AI tools produce disproportionately often, not just the generic patterns every SAST tool already knows to look for.
Common vulnerabilities found in vibe-coded apps
Vulnerability class | Why AI tools introduce it | Real-world evidence |
Broken authentication & missing authorization | Auth logic requires reasoning about who should access something, not just whether the code runs, a distinction models frequently get wrong | Widely documented across vibe-coded app breaches in 2025–2026 |
Hardcoded secrets & exposed API keys | Prompted code often includes credentials inline for speed/simplicity, with no prompt-level instruction to use a secrets manager | AI-assisted commits expose secrets at roughly 2x the rate of human-written code |
Server-side request forgery (SSRF) | Generated request-handling code frequently doesn’t validate or restrict outbound URLs | A December 2025 study found all five major AI coding agents tested introduced SSRF in the same type of feature, 5 out of 5 |
Missing CSRF protection & security headers | These are opt-in configurations, not defaults, and prompts rarely specify them explicitly | The same study found zero of 15 tested applications implemented CSRF protection or set security headers |
Cross-site scripting (XSS) | Output encoding is easy to skip when a model is optimizing for “the feature works” | Found in 86% of AI-generated code samples across five major LLMs in CSET testing |
Insecure AI-suggested dependencies | Models sometimes recommend packages by name-pattern association rather than verified security posture | Documented as a recurring theme in AI code security research through 2025–2026 |
Case study: the Moltbook breach
The Moltbook breach is the clearest public example to date of what happens when a fully AI-generated application ships without a security review step. It’s worth walking through in detail, because the failure wasn’t exotic, it was a single, well-understood misconfiguration that a five-minute checklist item would have caught.
Background
Moltbook launched publicly on January 28, 2026, marketed as a social network built exclusively for AI agents, a Reddit-style feed where autonomous agents could post, comment, vote, and build reputation through a karma system, with 17,000 human “owners” registering and operating agent accounts behind the scenes. Its creator, Matt Schlicht, stated publicly that he hadn’t written a single line of code himself, describing his role as providing the vision for the technical architecture while AI tools handled the implementation. The platform went viral within hours, drawing attention from prominent figures in the AI community, and grew to roughly 1.5 million registered agent accounts in a matter of days.
Timeline
- January 28, 2026, Moltbook opens to the public and goes viral almost immediately.
- January 31, 2026, 21:48 UTC, Security researchers at Wiz, conducting a routine, non-intrusive review by browsing the platform like ordinary users, discover a publishable Supabase API key embedded directly in the site’s client-side JavaScript. Security researcher Jameson O’Reilly independently discovered the same underlying issue around the same time, as later reported by 404 Media.
- Within minutes of discovery, Wiz confirms the exposed key grants full, unauthenticated read and write access to the platform’s entire production database.
- Same day, Wiz contacts the Moltbook maintainer to disclose the issue responsibly.
- Within hours, Moltbook secures the immediate exposure with Wiz’s assistance. Remediation continues over multiple rounds as further exposed surfaces come to light, first sensitive tables, then write access, then additional resources discoverable through the app’s GraphQL layer.
- After verification, Wiz deletes all data it accessed during the research and fix-verification process, consistent with responsible disclosure norms.
Technical root cause
The root cause was a single missing control, not a chain of exotic exploits. Moltbook’s backend ran on Supabase, a popular open-source Firebase alternative that pairs a hosted PostgreSQL database with a REST API, a common choice for AI-generated applications because of how quickly it can be wired up. Supabase’s public API key is safe to expose on the client side by design; it functions like a project identifier rather than a secret. But that safety depends entirely on Row Level Security (RLS) being explicitly configured on every table. Without RLS policies in place, the same “safe” public key becomes a master key to the entire database.
Moltbook never enabled RLS on its production tables. The application’s frontend also exposed table names directly, which made enumerating and dumping the database’s contents straightforward once the key was in hand. In effect, the AI-generated backend had working functionality and zero enforced access control layered underneath it, a working app that nothing was actually protecting.
What was exposed
With unauthenticated read and write access to the full database, researchers confirmed they could:
- Access roughly 1.5 million API authentication tokens tied to services including OpenAI, Anthropic, AWS, GitHub, and Google Cloud
- View tens of thousands of registered email addresses (Wiz’s initial figures cited around 35,000; later reporting from other outlets cited different subsets of that number, illustrating how differently “affected accounts,” “verified emails,” and “registered owners” can be counted after a breach)
- Read private messages exchanged between agents, some of which contained additional plaintext API keys shared inside conversations
- Confirm that writes to the database surfaced immediately in Moltbook’s live production feed, meaning an attacker could have injected content, including prompt injection payloads, directly into active agent conversations
- Impersonate any agent on the platform with a single authenticated-feeling API call, including high-karma accounts and well-known persona agents, since the exposed key granted full account control rather than just read access
- Confirm that the platform had no rate limiting and no way to verify whether a registered “agent” was actually AI-driven or a human posting through a script, the 1.5 million agent accounts sat behind only 17,000 verified human owners, an 88:1 ratio that suggested a large share of the platform’s “AI agent” activity was actually scripted human behavior
The write-access dimension is what separates this incident from a typical data leak. A pure read exposure is a privacy problem. Read-and-write access on a platform where autonomous agents act on what they read introduces an integrity problem on top of it, an attacker could shape what agents believed was happening and, potentially, what they did next.
Response and remediation
Moltbook’s maintainer moved quickly once notified, closing the initial exposure within hours of first contact. But the incident also illustrated something specific to fast-shipped, AI-generated applications: security surfaced in layers rather than all at once. Each round of verification by Wiz uncovered another exposed surface, first the core sensitive tables, then the broader write access, then additional resources reachable through the application’s GraphQL API, requiring several iterations of hardening rather than a single fix. That pattern, more than the initial misconfiguration itself, is the part AppSec teams evaluating AI-generated codebases should pay closest attention to: a clean scan on day one doesn’t mean the surface area has actually been mapped.
Lessons for AppSec teams
- A single missing default can be the entire security model. RLS isn’t an edge-case setting, on a Supabase-backed application, it’s the difference between a safe public key and an open database. Any AI-generated backend using a similar backend-as-a-service pattern needs that control verified explicitly, not assumed.
- Client-side code review isn’t optional, even for “just a public key.” The exposed key wasn’t hidden, it was sitting in plain client-side JavaScript, discoverable through completely ordinary browsing. AI coding tools don’t reliably flag when a normally-safe pattern becomes dangerous because of a missing companion setting.
- Write access changes the severity calculus. When scoping a review of an AI-generated application, don’t stop at “can data be read.” Confirm whether it can be written, and if so, what downstream systems, including other AI agents, act on that data automatically.
- One clean pass isn’t enough. Moltbook’s remediation required multiple rounds as new exposed surfaces surfaced. Treat an initial fix as the start of a review process, not the end of one, especially on applications built quickly with AI tools.
- This is a solvable defaults problem. The most direct fix isn’t asking individual builders to become security experts, it’s AI code-generation tools enabling RLS by default on any backend they scaffold, and deployment platforms proactively scanning for exposed credentials and unsafe configurations before an app goes live.
How the scanner works
- Connect or paste your code. Point the scanner at a repository, or paste code generated by Claude Code, Cursor, Lovable, Replit, Devin, or another AI coding tool.
- Automated multi-layer analysis. The scanner checks against the OWASP Top 10 alongside a ruleset built specifically around the vulnerability patterns AI tools produce disproportionately often, missing framework-level access controls, hardcoded secrets, SSRF-prone request handling, and insecure dependency suggestions.
- Graded report with fix guidance. You get a prioritized report (critical/high/medium/low) with the specific line, the vulnerability class, and a concrete remediation step, not just a flag.
How to secure AI-generated code: a 10-point checklist
- Never deploy AI-generated code to production without a security scan, regardless of how “finished” the feature looks.
- Explicitly enable framework-level access controls (e.g., Row Level Security), don’t assume the AI tool turned them on.
- Move all credentials out of generated code and into a secrets manager before the first commit.
- Add input validation and outbound request allow-listing to any AI-generated code that makes server-side requests.
- Confirm CSRF protection and standard security headers are present, check, don’t assume.
- Run output encoding checks on any user-facing rendering path to catch XSS before it ships.
- Review AI-suggested dependencies against a known-vulnerability database before installing them.
- Treat authentication and authorization logic as mandatory human-review zones, even in an otherwise AI-generated codebase.
- Re-scan after every significant AI-assisted change, not just at initial launch, vulnerabilities compound with iteration speed.
- Build a lightweight review gate into your workflow so AI-generated code can’t merge without passing a security check.
Conclusion
None of this is a reason to stop building with AI coding tools the speed they unlock is real, and it isn’t going away. It’s a reason to stop treating “the feature works” as a proxy for “the feature is safe.” Moltbook didn’t fail because vibe coding is inherently reckless; it failed because one default setting was never turned on, and nothing in the pipeline was positioned to catch it before launch. That’s the gap a vibe coding security scanner exists to close not by slowing teams down, but by putting a review step where the AI tool itself doesn’t have one.
The trend line is what makes this urgent rather than theoretical. Confirmed CVEs tied to AI-generated code roughly doubled month over month through the first quarter of 2026, and that’s with only a fraction of AI-generated applications getting any kind of external security review at all. The teams that come out ahead won’t be the ones that slow down their AI-assisted development they’ll be the ones that build a scan into the workflow as a default step, the same way tests and linting became defaults a decade ago.
If you’re shipping code generated by Claude Code, Cursor, Lovable, Replit, or any other AI coding tool, the fastest way to find out where you stand is to scan it. Talk to our experts for detailed scanning services
