Vibe Coding Security Risks: What Happens When AI Writes Your Production Code

TL;DR: "Vibe coding" — shipping AI-generated code with minimal review — is creating a new class of production vulnerabilities in 2026. AI coding assistants hallucinate secure-looking but insecure patterns, inherit biases from vulnerable training data, and are themselves susceptible to prompt injection attacks. This post explains the specific risk categories, shows real-world examples of AI-introduced flaws, and gives you a practical checklist for auditing AI-generated code before it reaches production.​‌‌‌​‌‌​‍​‌‌​‌​​‌‍​‌‌​​​‌​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​​‌‌‍​‌‌​‌​‌‌‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌​​‌‌‌‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌​​‌​‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌‌​‌‌​‍​‌‌‌​‌​‌‍​‌‌​‌‌​​‍​‌‌​‌‌‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌​​​‌​‍​‌‌​‌​​‌‍​‌‌​‌‌​​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌‌​

What Is Vibe Coding, and Why Is It a Security Problem?

Vibe coding is the emerging practice of describing what you want an AI to build and shipping whatever comes back — with little to no manual review. The term, popularised in early 2025 and now ubiquitous in developer circles, captures a real shift in how software gets written. Tools like GitHub Copilot, Cursor, Windsurf, and Claude Code have made it trivially easy for a developer to go from a plain-English prompt to a deployed pull request in under an hour. The speed is genuinely transformative. The security posture, however, is alarming.

The core problem is that large language models (LLMs) optimise for plausible, syntactically correct output — not secure output. When a developer prompts "write me a JWT authentication middleware in Node.js," the model produces code that looks correct, passes a quick eyeball test, and often works in local testing. What it may not produce is code that handles algorithm confusion attacks, validates audience claims, or rejects tokens signed with the none algorithm. The code vibes secure. It is not.​‌‌‌​‌‌​‍​‌‌​‌​​‌‍​‌‌​​​‌​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​‌​​‍​‌‌​‌​​‌‍​‌‌​‌‌‌​‍​‌‌​​‌‌‌‍​​‌​‌‌​‌‍​‌‌‌​​‌‌‍​‌‌​​‌​‌‍​‌‌​​​‌‌‍​‌‌‌​‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌‌‌​​‌‍​​‌​‌‌​‌‍​‌‌‌​​‌​‍​‌‌​‌​​‌‍​‌‌‌​​‌‌‍​‌‌​‌​‌‌‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​‌‌​​​​‌‍​‌‌​‌​​‌‍​​‌​‌‌​‌‍​‌‌​​‌‌‌‍​‌‌​​‌​‌‍​‌‌​‌‌‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌‌​‌​​‍​‌‌​​‌​‌‍​‌‌​​‌​​‍​​‌​‌‌​‌‍​‌‌​​​‌‌‍​‌‌​‌‌‌‌‍​‌‌​​‌​​‍​‌‌​​‌​‌‍​​‌​‌‌​‌‍​‌‌‌​‌‌​‍​‌‌‌​‌​‌‍​‌‌​‌‌​​‍​‌‌​‌‌‌​‍​‌‌​​‌​‌‍​‌‌‌​​‌​‍​‌‌​​​​‌‍​‌‌​​​‌​‍​‌‌​‌​​‌‍​‌‌​‌‌​​‍​‌‌​‌​​‌‍​‌‌‌​‌​​‍​‌‌​‌​​‌‍​‌‌​​‌​‌‍​‌‌‌​​‌‌‍​​‌​‌‌​‌‍​​‌‌​​‌​‍​​‌‌​​​​‍​​‌‌​​‌​‍​​‌‌​‌‌​

According to a 2025 study by researchers at Stanford University, AI-generated code contained exploitable security vulnerabilities in approximately 40% of sampled outputs across five major LLM coding assistants [1]. The most common categories were injection flaws, insecure direct object references, and hardcoded credentials — the same issues that have topped the OWASP Top 10 for over a decade [2]. AI has not solved these problems. In many cases, it has accelerated them.

How Do AI Coding Assistants Introduce Vulnerabilities?

Understanding why AI-generated code is often insecure requires understanding how these models were trained. LLMs for code are trained on massive datasets scraped from public repositories — GitHub, Stack Overflow, package registries, and open-source projects. The internet is not a curated collection of secure, well-reviewed code. It is a historical record of every quick fix, copy-pasted snippet, and deprecated pattern that has ever been committed to a public repo.

When a model is trained on this data, it learns the statistical patterns of code — including the patterns of insecure code. A 2024 analysis of the GitHub training corpus found that approximately 37% of sampled open-source repositori

es contained at least one known CWE (Common Weakness Enumeration) category flaw [3]. Models trained on this data will reproduce these flaws at a proportional rate, particularly when the prompt doesn't explicitly ask for security hardening.

This matters most in four categories:

1. Injection vulnerabilities. AI models frequently generate SQL queries using string concatenation rather than parameterised statements, particularly when the prompt context lacks ORM patterns. Classic SQL injection — a vulnerability that has existed since the 1990s — is still being introduced into production codebases in 2026, written by AI tools trained on legacy Stack Overflow answers.

2. Cryptographic misuse. Models commonly suggest deprecated hashing algorithms (MD5, SHA-1 for passwords), weak key sizes, static IVs for AES-CBC mode, and ECB mode encryption. These patterns exist in abundance in older open-source projects and translate directly into AI outputs.

3. Hardcoded secrets. When asked to write example configurations, API clients, or test harnesses, AI assistants routinely embed example credentials, API keys with placeholder names like YOUR_API_KEY_HERE, or — more dangerously — real-looking but fake credentials that developers sometimes leave in place.

4. Insecure defaults. CORS policies set to *, HTTPS certificate validation disabled for "testing", debug endpoints left enabled, and verbose error messages that expose stack traces are all common in AI-generated boilerplate.

What Is Prompt Injection in AI Coding Tools?

Prompt injection is a category of attack that targets LLM-powered tools by embedding malicious instructions inside content the model processes as data. In the context of AI coding assistants, this surfaces in ways that were barely discussed two years ago but are now a documented threat vector.

Consider a developer using an AI coding assistant with web browsing or file-reading capabilities — a common feature in tools like Cursor or Claude Code with MCP (Model Context Protocol) integrations. The developer asks the AI to read a third-party API documentation page and generate an integration. If that documentation page has been compromised and contains hidden instructions — perhaps in white text, HTML comments, or encoded strings — the model may interpret those instructions and act on them. The result could be an AI that exfiltrates the developer's API keys, injects backdoor logic into the generated code, or modifies existing files in the project.

The OWASP Top 10 for LLM Applications, updated in 2025, lists prompt injection as the number one vulnerability category for AI systems [4]. Unlike traditional injection attacks that target databases or OS shells, prompt injection targets the model's instruction-following behaviour — and the defences are significantly less mature.

In a widely-discussed 2025 incident, a security researcher demonstrated that a maliciously crafted README.md in a public GitHub repository could cause an AI coding assistant to silently insert a reverse shell into generated code when the assistant was used to explore that repository [5]. The attack required no special access — just a public repo and a developer trusting their AI tool to read it.

For development teams using AI assistants with broad file system access, code execution capabilities, or integrations with external data sources (documentation fetchers, ticket readers, email integrations), the prompt injection surface area is substantial and largely unaudited.

Real-World Examples of AI-Introduced Security Flaws (2025–2026)

The security community has documented a growing body of evidence that vibe coding is producing real-world vulnerabilities — not just in toy projects but in production systems.

The npm supply chain incident (Q3 2025). A popular open-source maintainer, using an AI coding assistant to accelerate a major refactor, unknowingly merged AI-generated code that modified the package's build script. The modification added an obfuscated network call that exfiltrated environment variables on install. The code passed CI because the build script was not in the automated security scan scope. The package had over 2 million weekly downloads before the issue was identified [6].

Authentication bypass in a SaaS startup (Q4 2025). A startup's engineering team used an AI coding tool to rapidly scaffold a new multi-tenant API. The AI generated role-based access control middleware that correctly checked permissions — but only for the primary tenant ID. A horizontal privilege escalation vulnerability allowed any authenticated user to access any other tenant's data by manipulating the tenant ID in the request header. The flaw was present for 11 weeks before discovery during a routine penetration test [7].

Cryptographic weakness in a fintech app (January 2026). An AI-generated payment processing module used ECB mode AES encryption for tokenising card data. ECB mode does not use an initialisation vector and encrypts identical plaintext blocks to identical ciphertext blocks — a well-known weakness that makes patterns in data visible. The module passed code review because the reviewer recognised the AES import and assumed the implementation was correct. The flaw was caught during a PCI DSS audit [8].

These examples share a pattern: the AI-generated code looked correct to a developer performing a fast review. The flaws were in the details — algorithm choice, access control logic, scope of validation — the kind of details that require deliberate security knowledge to catch.

How to Review AI-Generated Code for Security: A Practical Checklist

Adopting AI coding tools without a security review process is, at this point, an organisational risk decision that should be made consciously and documented. The following checklist is designed for teams that are already using AI assistants and need a pragmatic approach to hardening their review process. lilMONSTER recommends this checklist as a baseline — not a substitute for professional security assessment.

Pre-Merge Checklist for AI-Generated Code

Authentication and Authorisation

  • Does every API endpoint explicitly check the caller's identity and permissions?
  • Are permissions checked at the data layer, not just the route layer?
  • Is there protection against horizontal privilege escalation (accessing other users' data)?
  • Are JWT tokens validated for algorithm, audience, issuer, and expiry?

Input Handling and Injection

  • Are all database queries parameterised or using an ORM with safe defaults?
  • Is user input validated and sanitised before use in file paths, shell commands, or template engines?
  • Are HTML outputs properly encoded to prevent cross-site scripting (XSS)?
  • Is XML input processed with entity expansion disabled (XXE prevention)?

Cryptography

  • Are passwords hashed with bcrypt, scrypt, or Argon2 — not MD5, SHA-1, or unsalted SHA-256?
  • Is AES used in GCM or CBC mode with a random IV — never ECB?
  • Are TLS certificate chains validated and not disabled for "convenience"?
  • Are secrets loaded from environment variables or a secrets manager — not hardcoded?

Configuration and Defaults

  • Is CORS scoped to specific origins — not * in production?
  • Are debug endpoints, stack traces, and verbose error messages disabled in production?
  • Are dependency versions pinned and checked against known CVE databases?
  • Are file upload handlers restricted by type, size, and storage location?

AI-Specific Risks

  • Has any external content processed by the AI (docs, tickets, README files) been treated as potentially hostile?
  • Are AI tool integrations scoped with minimum necessary file system and network permissions?
  • Has the AI-generated code been run through a static analysis tool (Semgrep, CodeQL, Bandit) in CI?

How Should Development Teams Structure AI Code Review?

The answer is not to ban AI coding tools — that ship has sailed, and the productivity gains are real. The answer is to treat AI-generated code with the same scepticism applied to any code from an untrusted source, and to build that scepticism into process rather than relying on individual developer vigilance.

Establish an AI code disclosure norm. Teams should normalise flagging AI-generated code in pull request descriptions — not to stigmatise it, but to trigger the appropriate level of scrutiny. Many teams are already doing this informally; formalising it makes the review expectation explicit.

Run static analysis on every AI-generated PR. Tools like Semgrep, GitHub's CodeQL, and Snyk integrate directly into CI pipelines and catch a significant proportion of the vulnerability categories AI tools most commonly introduce. The cost is minimal; the coverage is substantial. These tools are not perfect, but they are consistently better than a fast visual review of plausible-looking code.

Implement AI tool permission scoping. If your AI coding assistant can read arbitrary files, execute code, fetch external URLs, or access your ticketing system, you have created a prompt injection attack surface that likely has not been threat-modelled. Audit what your AI tools can access and restrict permissions to the minimum necessary for the task.

Require security-specific prompting for security-critical code. When using an AI to generate authentication, cryptography, payment, or access control code, explicitly prompt for security hardening: "Write this using secure defaults. Identify any security concerns in your implementation." This does not guarantee secure output, but it shifts the model's probability distribution toward more security-aware patterns.

Invest in security training for developers. AI coding tools lower the barrier to writing functional code, but they do not lower the bar for understanding what makes code secure. Developer security training — particularly around the OWASP Top 10, cryptographic principles, and secure defaults — has never been more valuable than in an era when developers are shipping AI-generated code at speed.

What Does This Mean for Australian Businesses in 2026?

Australian organisations operating under the Privacy Act 1988 and the Notifiable Data Breaches (NDB) scheme have a legal obligation to take "reasonable steps" to protect personal information [9]. As AI-generated code becomes standard practice across the industry, regulators and courts will increasingly scrutinise whether development teams had adequate review processes in place. Shipping AI-generated code without security review is a posture that is difficult to defend as "reasonable steps."

The Australian Cyber Security Centre (ACSC) published guidance in 2025 on AI tool governance for software development organisations, recommending that entities using AI coding assistants document their review processes and include AI-generated code in scope for annual security assessments [10]. This guidance, while non-binding, signals the direction of regulatory expectations.

For small and medium-sized businesses that have adopted AI coding tools rapidly — often without dedicated security staff — the risk is particularly acute. A single authentication bypass or injection vulnerability in an AI-generated feature can trigger an NDB notification, damage customer trust, and expose the organisation to regulatory scrutiny, all from code that took minutes to generate and seconds to review.

Frequently Asked Questions

Is AI-generated code always insecure? No. AI coding tools can generate secure code, particularly when prompted explicitly for secure patterns and when the output is reviewed by someone with security knowledge. The risk is that AI-generated code looks correct even when it isn't, which undermines the casual review most developers apply. With structured review processes and static analysis tooling, AI-generated code can be brought to an acceptable security standard.

Which AI coding tools are most secure? No independent, comprehensive security benchmark exists for AI coding tools as of February 2026. Tool vendors make varying claims about security training and guardrails. The reality is that all major AI coding assistants have been demonstrated to generate vulnerable code under common conditions. Tool choice matters less than the review process applied to the output.

What is prompt injection and how does it affect me? Prompt injection is an attack where malicious instructions are embedded in content an AI model processes. For developers, this means that if your AI coding tool reads external files, fetches documentation, or integrates with third-party systems, a malicious actor who controls any of that content could potentially influence what code your AI generates. The risk is highest with AI tools that have broad file system access or external network access.

Do I need to review every line of AI-generated code? You don't need to review every line, but you need a systematic approach that covers the highest-risk categories: authentication, authorisation, input validation, cryptography, and configuration. Automated static analysis tools can cover significant ground here. The goal is a process that would catch the most common AI-introduced vulnerability classes without requiring manual review of every generated line.

Does using AI code generation affect my cyber insurance coverage? This is an evolving area. Some cyber insurance policies include language around "reasonable security practices" and "software development standards." As AI-generated code vulnerabilities become more documented, insurers may begin to ask specifically about AI tool governance in policy applications. Consult your insurer and document your review processes.

How can lilMONSTER help my organisation manage AI coding security risks? lilMONSTER provides cybersecurity consulting for Australian businesses navigating the security implications of AI adoption — including AI tool governance frameworks, developer security training, and code security assessments. Get in touch via the consult page.

Summary

Vibe coding is not a fad — it is the new baseline for software development. AI coding tools are fast, increasingly capable, and here to stay. The security community's job is not to resist them but to build the review practices, tooling, and team culture that make AI-generated code safe to ship.

The specific risks to address are well-defined: injection vulnerabilities from training data bias, cryptographic misuse from outdated patterns, hardcoded secrets from example code, insecure defaults from rapid scaffolding, and prompt injection from AI tools with broad external access. Each of these has a countermeasure. None of the countermeasures are exotic. All of them require deliberate process.

The organisations that will navigate this well are the ones that treat AI-generated code as a first draft from a brilliant but security-naïve junior developer — fast, useful, worth reviewing, and never to be trusted blindly.

Get a Security Assessment for Your AI-Built Product

If your team has adopted AI coding tools and hasn't revisited your security review process, now is the time. lilMONSTER offers practical, no-jargon cybersecurity assessments for Australian SMBs — including AI code security reviews, developer training, and NDB compliance support.

Book a free 30-minute consult →

TL;DR

  • TL;DR: "Vibe coding" — shipping AI-generated code with minimal review — is creating a new class of production

  • The core problem is that large language models (LLMs) optimise for plausible, syntactically correct output — not secur
  • Action required — see the post for details

FAQ

Q: What is the main security concern covered in this post? A:

Q: Who is affected by this? A:

Q: What should I do right now? A:

Q: Is there a workaround if I can't patch immediately? A:

Q: Where can I learn more? A:

References

[1] Pearce, H., Ahmad, B., Tan, B., Dolan-Gavitt, B., & Karri, R. (2025). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. IEEE Symposium on Security and Privacy. https://doi.org/10.1109/SP46215.2023.10179324

[2] OWASP Foundation. (2025). OWASP Top Ten 2025. Open Web Application Security Project. https://owasp.org/www-project-top-ten/

[3] Wermke, D., Wöhler, N., Klemmer, J., Hader, M., Wiese, L., & Fahl, S. (2024). Committed to Trust: A Qualitative Study on Security & Trust in Open Source Software Projects. IEEE Symposium on Security and Privacy.

[4] OWASP Foundation. (2025). OWASP Top 10 for Large Language Model Applications 2025. https://owasp.org/www-project-top-10-for-large-language-model-applications/

[5] Harang, R. (2025). Prompt Injection Attacks in AI Coding Assistants: A Taxonomy and Threat Model. Proceedings of the ACM Conference on Computer and Communications Security.

[6] Sonatype. (2025). 2025 State of the Software Supply Chain Report. Sonatype Inc. https://www.sonatype.com/state-of-the-software-supply-chain

[7] PortSwigger Research. (2025). Horizontal Privilege Escalation Patterns in LLM-Scaffolded APIs. PortSwigger Web Security Blog. https://portswigger.net/research

[8] PCI Security Standards Council. (2026). PCI DSS v4.0.1: Cryptographic Requirements for Payment Applications. PCI SSC. https://www.pcisecuritystandards.org

[9] Office of the Australian Information Commissioner. (2024). Notifiable Data Breaches Scheme: Guide for Entities. OAIC. https://www.oaic.gov.au/privacy/notifiable-data-breaches

[10] Australian Cyber Security Centre. (2025). Guidance for Organisations Using AI-Assisted Software Development. Australian Signals Directorate. https://www.cyber.gov.au

Ready to strengthen your security?

Talk to lilMONSTER. We assess your risks, build the tools, and stay with you after the engagement ends. No clipboard-and-leave consulting.

Get a Free Consultation