Vibe Coding Security Risks: 2026's Reckoning

RunFreeTools TeamJun 22, 20268 min read
Vibe Coding Security Risks: 2026's Reckoning

Vibe coding security risks, in one sentence

The biggest vibe coding security risks in 2026 are hardcoded secrets, broken access control, injection bugs, and fake "hallucinated" dependencies, because the AI that writes the code optimizes for output that runs, not output that is safe. That gap stopped being theoretical this year. A reported exposure at the AI app-builder Lovable, peer-reviewed studies finding that close to half of AI-generated code contains flaws, and the rise of an attack called "slopsquatting" turned vibe coding from a productivity story into a security one.

Last updated: June 22, 2026

Vibe coding, the practice of building software mostly by describing it to an AI and accepting what it generates, is now mainstream. Surveys put weekly AI-assistant usage among developers around 75%. The problem is that speed and security pull in opposite directions, and through the first half of 2026 the bill came due. This is a plain-English tour of what went wrong, the real risk categories, what slopsquatting actually is, and a checklist for shipping AI-built code without getting burned. For more developer-focused guides, browse our developer tools and guides.

What actually went wrong in 2026

Three separate stories collided and made "is vibe coding safe?" a question every founder started asking.

The Lovable incident. In April 2026, security researchers reported that Lovable, a popular tool that generates and hosts full apps from prompts, left sensitive data from older "public" projects readable by anyone who signed up for a free account. According to reporting by The Register, the exposed material reportedly included project source code, AI chat histories, and database credentials. Lovable's first response was to deny a breach: the company said code visibility on public projects was "intentional behavior" and "consistent by design," and it pointed at unclear documentation and at the bug-bounty platform HackerOne. It later issued a fuller statement acknowledging that a February 2026 backend permissions change had accidentally re-enabled access to chat histories on public projects.

This was not Lovable's first scare. In 2025, researcher Matt Palmer disclosed CVE-2025-48757, a flaw where weak database row-level security let unauthenticated attackers read and write to the database tables of generated sites. A scan reportedly found inadequate settings across roughly 170 of about 1,645 analyzed projects. The throughline of both episodes: the AI happily wired up a backend, and the security defaults around it were left wide open.

The studies. The standout data point comes from Veracode, whose 2025 GenAI Code Security Report tested more than 100 large language models across 80-plus coding tasks and found that 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability. Cross-site scripting and log injection were among the worst, failing 86% and 88% of the time, and Java was the riskiest language at over 70%. Veracode's Spring 2026 update found the picture had barely improved: security pass rates were stuck around 55% even as newer, larger models got better at writing code that simply works. Separate academic work points the same way: Carnegie Mellon researchers reported that 61% of AI code functioned correctly but only 10.5% passed a security review, and a Georgetown study found roughly 48% of generated snippets contained an insecure-code bug.

Slopsquatting. Attackers noticed that AI tools confidently invent package names that do not exist, and that the same fake names come back again and again. Registering those names is a brand-new supply-chain attack, covered below.

The real vibe coding risk categories

Most AI-generated security bugs fall into a handful of buckets. Knowing them tells you exactly what to look for in a review.

RiskWhat the AI doesWhy it bites youHardcoded secretsPastes API keys, DB passwords, and tokens directly into source filesKeys end up in git history and public repos; rotating them is painfulBroken authentication / access controlSkips ownership checks and row-level securityOne user can read another user's data (the core Lovable problem)Injection (SQLi, XSS)Builds queries via string concatenation; renders unescaped inputClassic, fully preventable bugs that still dominate the OWASP Top 10Vulnerable dependenciesPulls in outdated or unvetted packagesYou inherit every known CVE in the dependency treeHallucinated dependenciesImports packages that do not existOpens the door to slopsquatting (see below)

Hardcoded secrets deserve a special mention because they are the most common and the most quietly destructive. GitGuardian's State of Secrets Sprawl 2026 report found that 28.65 million new hardcoded secrets were pushed to public GitHub in 2025, a 34% jump year over year, and that AI-assisted commits leaked secrets at roughly twice the baseline rate (it reported a 3.2% leak rate on AI-assisted commits versus a 1.5% baseline). GitGuardian was careful to note this is not purely a tool failure, since developers still control what gets pushed, but the pattern is unmistakable: AI makes it easier than ever to commit a live key without noticing.

Slopsquatting and hallucinated dependencies, explained

When an AI assistant writes code, it sometimes tells you to install a package that does not exist. It is not lying on purpose; it is pattern-matching a plausible-sounding name. Slopsquatting is the attack built on top of that habit: a malicious actor registers the fake name on a public registry like PyPI or npm, so that the next developer who copy-pastes the AI's suggestion installs the attacker's code instead of a harmless 404. The term was coined by Python Software Foundation developer Seth Larson, blending "AI slop" with "typosquatting."

The reason this works is consistency. A USENIX Security 2025 paper, "We Have a Package for You!" by Spracklen and colleagues, tested 16 code-generating models across 576,000 generated samples and found that 19.7% of recommended packages did not exist. Open-source models hallucinated far more (about 21.7%) than commercial ones (about 5.2%), and across all of them the researchers catalogued more than 205,000 unique fake package names. Critically, 43% of hallucinated packages reappeared on all 10 runs of the same prompt, so an attacker does not need to scrape anything. They can watch a popular model, write down the names it invents, and register them.

This is not hypothetical. As reported in security coverage of the trend, researchers at Lasso Security demonstrated the idea early when they noticed models repeatedly suggesting a non-existent Python package, huggingface-cli; an empty placeholder uploaded under that name reportedly drew more than 30,000 downloads in three months. The defense is simple to state and easy to skip: before you install anything an AI suggests, confirm the package actually exists, is widely used, and is the one you meant.

How to vibe-code safely: the checklist

You do not have to stop using AI. You have to stop trusting it blindly. Treat every generation as a pull request from a brilliant but careless junior who has never been told about security. Then run this list.

  • Review the AI's output before you merge. Read every line. If you cannot explain what a block does, do not ship it. This single habit catches most injection and access-control mistakes.
  • Never hardcode secrets. No API keys, passwords, or tokens in source files. Use environment variables or a dedicated secrets manager, and load them at runtime.
  • Rotate and secure your keys. If a credential has ever touched a repo, a chat log, or an AI prompt, assume it is compromised and rotate it. The Lovable episode is a reminder that your prompts and generated code can leak.
  • Generate strong, unique secrets. When you do need a token, signing secret, or admin password, do not let the model autocomplete a weak one. Create high-entropy values with a dedicated secure password generator and store them in your secrets manager, never in code.
  • Verify every dependency. Before installing, check the package exists, has real download history and a real repo, and is spelled exactly right. This is your slopsquatting defense.
  • Scan dependencies automatically. Run software composition analysis (Dependabot, Renovate, or Snyk) on every build and fail the build on critical and high-severity findings.
  • Run SAST in CI. Wire a static analysis scanner such as Semgrep, CodeQL, or Snyk Code into your pipeline and block merges on high-severity issues. Security researchers consistently call this the single highest-impact automation for AI-generated code.
  • Scan for secrets, too. Add GitLeaks, TruffleHog, or your platform's built-in secret scanning as a pre-commit hook and a CI gate so a stray key never reaches main.
  • Verify integrity where it matters. When you download a binary, dependency, or release artifact, confirm its checksum with a file hash generator so you know the bytes match what the author published and nothing was swapped in transit.

What this means for you

If you are building a quick prototype or a weekend project, vibe coding is fine. The danger arrives the moment that prototype touches real users, real money, or real data, because that is when broken auth and a leaked database key stop being embarrassing and start being a breach.

The practical mindset shift is this: AI moved the bottleneck. Writing code is no longer the slow part; verifying it is. So the time you save by generating a feature in two minutes should be partly reinvested in review and scanning, not pocketed entirely. The teams that get burned in 2026 are the ones treating "it works in the preview" as "it is ready to ship." The teams that do well bolt automated security checks onto their pipeline once and let them run on every commit forever.

Key takeaways

  • Roughly 45% of AI-generated code introduces an OWASP Top 10 vulnerability (Veracode, 2025), and AI code carries about 2.74x more flaws than human code.
  • The 2026 Lovable episode showed the pattern in the wild: source code, credentials, and chat histories from "public" projects were reportedly readable by anyone, on top of an earlier row-level-security flaw (CVE-2025-48757) affecting around 170 apps.
  • Hardcoded secrets are the most common and most damaging mistake; AI-assisted commits leak secrets at roughly twice the baseline rate (GitGuardian, 2026).
  • Slopsquatting weaponizes hallucinated dependencies: AI invents fake package names predictably (about 19.7% of suggestions in one 576,000-sample study), and attackers register them.
  • You can vibe-code safely by reviewing output, scanning dependencies and secrets, running SAST in CI, verifying every package, and never hardcoding credentials.

Try the tool from this post

Password Generator

Create strong, random passwords.

Open Password Generator

Frequently asked questions

Vibe coding is not inherently insecure, but research consistently shows AI-generated code ships with vulnerabilities at a high rate. Veracode's 2025 GenAI Code Security Report found 45% of AI-generated samples introduced an OWASP Top 10 flaw, and Carnegie Mellon researchers found that while 61% of AI code worked, only 10.5% passed a security review. The risk is real but manageable: treat AI output as a first draft from a fast junior developer, then review it, scan it, and never ship it unchecked.

In April 2026, security researchers reported that AI app-builder Lovable left source code, database credentials, and AI chat histories from older 'public' projects readable by anyone with a free account. Lovable initially denied a breach, telling The Register the code visibility was 'intentional behavior,' before issuing a fuller statement acknowledging it had accidentally re-enabled access to chat histories during a February 2026 backend change. It followed an earlier 2025 flaw (CVE-2025-48757) in which weak database row-level security exposed data across roughly 170 generated apps.

Slopsquatting is a supply-chain attack where someone registers a fake package name that AI coding tools repeatedly hallucinate, hoping developers copy-paste and install it. The term was coined by Python Software Foundation developer Seth Larson. A USENIX Security 2025 study found that across 576,000 AI-generated code samples, 19.7% of recommended packages did not exist, producing more than 205,000 unique fake names attackers can simply register and wait for.

Hallucinated dependencies are software packages an AI suggests in code that do not actually exist in any registry. The model invents a plausible-sounding name based on patterns it has seen. They are dangerous because the same fake names recur predictably: the USENIX study found 43% of hallucinated packages reappeared on every one of 10 identical prompts, giving attackers a reliable list of names to squat on.

Review every line before merging, run a static analysis (SAST) scanner like Semgrep or CodeQL in CI, scan dependencies for known vulnerabilities, verify that every imported package actually exists and is the real one, and run a secret scanner such as GitLeaks or TruffleHog to catch hardcoded keys. Never hardcode credentials; use environment variables or a secrets manager, and rotate any key that has touched source control.

No. Veracode's research found AI-generated code contains roughly 2.74x more vulnerabilities than human-written code, and a 2026 GitGuardian report found AI-assisted commits leaked secrets at about twice the baseline rate of all public GitHub commits. AI is faster, not safer, so the human review and automated scanning steps matter more, not less.

Share this article

Send it to a teammate or save the link for later.

Related tools

Related articles

A mailbox receiving new tools, guides and feature updates

New tools, straight to your inbox

A short note whenever we ship a new free tool or guide. No spam, unsubscribe in one click.

  • No spam
  • Unsubscribe anytime
  • Your email is safe
8min left