Vibe Coding Is a Security Risk: The Hidden Cost of AI-Generated Code

Apache Struts and the Cost of “It Works”

Apache Struts CVE-2017-5638 is still the cleanest reminder that “working code” and “safe code” are different species. Equifax didn’t get hit because OGNL injection was mysterious; they got hit because a known RCE was left unpatched long enough to become a breach headline, and 147 million records walked out the door. That’s the part people keep forgetting when they paste AI-generated code into a repo and call it productivity. The code compiles. Great. So did the exploit path.

Vibe coding is just a nicer label for a familiar failure mode: you ask a model for a feature, it gives you something plausible, and you skip the boring part where you verify the control flow, the auth boundary, and the error handling. Security researchers are already finding the same old sins in new clothes: unsafe deserialization, SSRF, weak input validation, broken access control, hardcoded secrets, and dependency choices that look reasonable until you trace them. The LLM didn’t invent these bugs. It just accelerates your ability to ship them.

Why AI-Generated Code Fails in Predictable Ways

Models are very good at producing code that resembles code people have seen before. That is not the same as producing code that survives hostile input. If you ask for a file upload endpoint, you often get MIME-type checks, maybe a filename sanitize, and a cheerful assumption that the client is honest. If you ask for JWT auth, you may get signature verification and no issuer validation, audience check, or key rotation story. That’s not “edge case” territory; that’s the first thing an attacker tests.

The deeper problem is that LLMs optimize for plausibility, not invariants. They don’t know which branch must never be reachable, which redirect must be pinned, or which exception path leaks a token. In a breach investigation, that’s the sort of detail that decides whether you’re looking at a bug bounty report or a customer notification. The model will happily generate a neat abstraction layer over a bad assumption. It’s very tidy right up until it isn’t.

SolarWinds Proved the Pipeline Is the Product

SolarWinds/SUNBURST should have killed the fantasy that security lives only in the final application. A backdoored Orion DLL was signed, shipped, and sat undetected for months while roughly 18,000 customers inherited the blast radius. That was a supply-chain compromise in the classic sense: the attacker didn’t need to break every endpoint when they could poison the thing everyone trusted.

AI-generated code creates a smaller version of the same problem inside your own pipeline. You are now importing logic from a system that cannot prove provenance, cannot explain why it chose a pattern, and cannot tell you whether it has seen your secret before in training. If you’re letting a model generate internal libraries, auth glue, or IaC snippets, you’ve effectively added a junior developer with perfect confidence and no memory of your threat model. Charming.

And yes, “just review the code” is the standard advice. It’s also incomplete. Review catches syntax, obvious logic errors, and the occasional security faceplant. It does not reliably catch semantic drift in a 400-line generated helper that looks fine in a diff but quietly relaxes tenant isolation in production. You need tests that assert security properties, not just coverage numbers that make a dashboard feel productive.

Barracuda ESG and the Appliance Problem Nobody Wants

Barracuda ESG CVE-2023-2868 was a nasty reminder that some products fail so hard the vendor told customers to physically replace the appliance. China-nexus UNC4841 used the zero-day to compromise email security gateways, and the remediation was not “apply a patch when convenient.” It was “rip it out.” That is what happens when the trust boundary is the box itself and the box is owned.

AI-generated code can create the software equivalent of that appliance problem: a component so entangled with secrets, credentials, and downstream trust that you cannot patch your way out of a bad design. If the model writes a token broker, an internal proxy, or a permissions layer with undocumented assumptions, you may not discover the flaw until the only safe fix is replacement. Security people love elegant architectures until the incident report asks who designed the blast radius.

Snowflake, Stolen Credentials, and the Boring Attack Path

The 2024 Snowflake customer breaches were not some cinematic AI exploit. They were stolen credentials from infostealer malware, weak or absent MFA on accounts, and a lot of expensive regret. More than 165 customers were affected because the attack path was simple, reliable, and boring. That’s the part that should scare you. Most real intrusions still start with ordinary hygiene failures, not exotic zero-days.

That’s why the “AI-generated code is the risk” argument is too narrow if you stop there. The real issue is that vibe coding encourages speed in the exact places where attackers benefit from your haste: auth, secrets handling, logging, and dependency selection. A model-generated login flow that forgets rate limiting or MFA hooks doesn’t need to be clever. It just needs to be deployed. Attackers are happy to meet you halfway.

What You Should Actually Do Before the Merge

Start by treating generated code as untrusted input. That means the same scrutiny you’d apply to a third-party library from a vendor you haven’t audited, because functionally that’s what it is. Require tests that prove security properties: no unauthenticated access to privileged routes, no SSRF to metadata endpoints, no secret material in logs, no unsafe deserialization paths. If you can’t write the test, you probably don’t understand the code well enough to ship it.

Use SAST and dependency scanning, sure, but don’t kid yourself that a green dashboard means safety. Most scanners are good at known patterns and mediocre at the weird, business-specific logic that actually gets you breached. The contrarian move here is to slow down the parts you think AI should speed up. Put the model on scaffolding: generate boilerplate, not trust decisions. Let it draft, not decide.

The Bottom Line

If you use AI to generate code, assume it will confidently produce security bugs that look normal in review. Put generated code behind mandatory tests for auth, input handling, and secret exposure before it gets near production.

Do not let models write security-critical glue unchecked: token validation, access control, payment logic, tenant isolation, or anything that touches credentials. That’s where “move fast” turns into “write your own incident report.”

References

• Apache Struts CVE-2017-5638: https://nvd.nist.gov/vuln/detail/CVE-2017-5638
• Equifax breach timeline and findings: https://www.equifaxsecurity2017.com/
• SolarWinds SEC filing and incident disclosure: https://www.sec.gov/ixviewer/ix.html?doc=/Archives/edgar/data/1739940/000162828021000106/swi-20201231.htm
• Barracuda ESG CVE-2023-2868 advisory: https://www.barracuda.com/company/legal/esg-vulnerability
• Snowflake customer incident reporting and guidance: https://www.snowflake.com/blog/customer-security-incident/