Vibe Coding: Why AI-Generated WordPress Plugins Are a Security Risk

Veracode tested over 100 large language models on security-sensitive coding tasks, and 45% of the AI-generated code introduced an OWASP Top 10 vulnerability. That isn't a rounding error. It's close to a coin flip. When you ask a model to "build me a WordPress plugin that uploads a CSV" or "add an endpoint that downloads a log file," there's an even chance the code it hands back contains a hole an attacker can drive through.

This is the core problem with vibe coding: you describe what you want in plain English, the model produces working code, and almost nobody checks the parts that don't show up in a happy-path demo. The plugin loads, the button works, the CSV imports, and the missing capability check sits there quietly until someone finds it.

The trend line is steeper than most site owners realize. The "Vibe Security Radar" tracked roughly 18 vibe-coded vulnerability cases across the second half of 2025, then 56 in just the first three months of 2026. March 2026 alone produced 35 cases, more than the entire previous year combined. These aren't theoretical findings sitting in a researcher's notebook either. AI-generated WordPress plugins are getting exploited within weeks of deployment, often before the owner even knows there's a problem.

Why Vibe Coding Produces Insecure WordPress Plugins

Vibe coding feels like a superpower right up until it isn't. You type a request, you get code, you ship it. The speed is real and the productivity gains are real. But the model isn't reasoning about your threat model. It's predicting the most plausible next token given everything it has seen, and most of the code it trained on prioritized "does this run" over "is this safe."

Columbia University research explains the mechanism in a way that should make every developer uncomfortable. Models are optimized to make errors go away. The fastest path to making an error disappear can be to delete the very validation step that was protecting the site. When a nonce check or a capability gate causes a test to fail, the model doesn't see a security wall. It sees a bug blocking the code, so it removes the obstacle and the code runs clean. The site is now wide open, and the diff looks like a successful fix.

That dynamic compounds across an entire plugin. Every time you ask the model to "make the upload work" or "fix the permission error," you nudge it toward stripping out exactly the guardrails that WordPress spent fifteen years teaching developers to add. The recurring vulnerability classes in vibe-coded plugins are depressingly familiar: SQL injection from unsanitized POST input, missing nonce verification on AJAX handlers, broken access control, arbitrary file read and write via path traversal, and reflected cross-site scripting. None of these are new. They're the same bugs that have plagued WordPress since the beginning, now generated at machine speed.

If you want a fuller picture of how attackers are adapting to AI-assisted development, our breakdown of how to defend WordPress in the AI era walks through the shift from manual probing to automated, AI-driven scanning of fresh plugin code.

A Real Path Traversal Bug Hiding in Vibe-Coded Code

Let's make this concrete instead of abstract. Path traversal is one of the most common flaws in AI-generated plugins because it hides in code that looks completely reasonable. You ask the model for an admin tool that previews a log file, and it gives you something that works perfectly in the demo. The file loads, the content shows up, everyone moves on.

Here's the kind of handler that comes back:

add_action( 'wp_ajax_vp_read_log', 'vp_read_log' );
function vp_read_log() {
    $file = $_POST['file']; // attacker-controlled, no sanitization
    $path = WP_CONTENT_DIR . '/logs/' . $file;
    echo file_get_contents( $path ); // no capability check, no nonce
    wp_die();
}

It works. It also lets anyone read any file on the server. There's no current_user_can() check, so any logged-in user, including a lowly subscriber, can call it. There's no nonce, so it's wide open to CSRF. And because $_POST['file'] flows straight into the path, an attacker sends file=../../../wp-config.php and walks away with your database credentials, your auth salts, and your secret keys. From there the whole site is theirs.

The model didn't do anything malicious. It built the feature you asked for. It just never added the three things a careful developer adds by reflex: a capability check, nonce verification, and input that's constrained to an allowlist or run through basename() and realpath(). If you're fuzzy on why that nonce matters and what it actually protects against, our guide on what nonces protect and what they don't covers the gap. A nonce alone wouldn't have saved this handler, but its absence is one of three separate failures stacked on top of each other.

Multiply this single handler across a plugin with a dozen AJAX endpoints, and you start to see why the case counts are climbing so fast. Each endpoint is an independent roll of the dice, and Veracode's research says the odds aren't in your favor.

What makes path traversal so easy to miss is that it never breaks the feature. A SQL syntax error throws a visible warning. A fatal PHP error shows up in your logs. But a path traversal bug behaves exactly like a working file reader, because that's precisely what it is. The model built a file reader. It just built one that reads any file instead of the specific files you intended. The bug is invisible until the day someone points it at wp-config.php instead of error.log, and by then your credentials are already gone.

The fix is three small lines the model didn't write. Add if ( ! current_user_can( 'manage_options' ) ) wp_die(); to gate access. Add check_ajax_referer( 'vp_log_nonce' ) to stop CSRF. And constrain the input with $file = basename( $file ); so ../ sequences can't escape the directory. None of that is exotic. It's the baseline every WordPress developer is supposed to internalize, and it's exactly what gets lost when a model optimizes for code that runs rather than code that's safe.

The Invisible Attack Surface of Manually Installed Plugins

Here's the part that turns a bad situation into a dangerous one. Plugins you install from the WordPress.org repository pass through a review process. It isn't perfect and it isn't a security audit, but it's a gate. Code gets eyes on it before it reaches millions of sites.

Vibe-coded plugins installed manually skip that gate entirely. Someone generates a plugin in an afternoon, zips it up, and uploads it straight to production. No repository review, no second pair of eyes, no automated scanning between the model's output and your live server. This creates an invisible attack surface. Your security plugin might dutifully check for known CVEs in repository plugins while a freshly generated, never-reviewed plugin with a textbook path traversal bug sits in wp-content/plugins completely unexamined.

This is the same structural risk that makes untrusted plugin code so dangerous in general. We've written before about the risks of running untrusted plugin code from nulled sources, and vibe-coded plugins fall into a similar bucket: code of unknown provenance running with full access to your database and filesystem. The difference is that nulled plugins are at least usually copies of code that was reviewed once. A one-off vibe-coded plugin may never have been reviewed by anyone, including the person who "wrote" it.

Attackers know this. Automated scanners now actively hunt for the signatures of AI-generated code: the telltale endpoint patterns, the missing nonces, the predictable handler names. They don't need a published CVE. They just need to find the pattern, and AI-generated plugins produce that pattern reliably. If you want to understand the broader mechanics of how these compromises unfold, our explainer on how WordPress sites get hacked maps the full chain from initial probe to persistent backdoor.

How to Vet AI-Generated Plugins Before They Reach Production

None of this means you should swear off AI-assisted development. The productivity is real, and used carefully, a model is a genuinely useful pair of hands. The problem isn't the tool. It's shipping the output without review. So treat every line of AI-generated code the way you'd treat a pull request from a contractor you've never met.

Start with the inputs. Every place user data enters the plugin, ask whether it's sanitized. Every $_POST, $_GET, and $_REQUEST should run through the right WordPress sanitization function before it touches a query, a path, or output. Then check the gates. Every AJAX handler, every admin action, every endpoint that changes state needs both a capability check and nonce verification. The path traversal example above failed on exactly these points.

Watch the file operations especially closely. Any time user input influences a file path, that's a candidate for traversal. Constrain it with basename(), validate against an allowlist, and resolve with realpath() to confirm the final path stays inside the directory you intended. Treat output the same way: anything echoed back to the browser needs escaping, or you've got reflected XSS waiting to happen.

We've built a dedicated checklist for vetting AI plugins before you install them that turns all of this into a step-by-step pass you can run in a few minutes. The discipline matters more than the speed. A plugin that takes ten extra minutes to review beats a plugin that takes ten weeks to recover from after a breach.

And review the code even when it looks finished. The most dangerous vibe-coded bugs aren't the ones that throw errors. They're the ones where everything works perfectly, the demo is flawless, and the only thing missing is the security check the model quietly removed to make your last error go away. Working code and safe code are not the same thing, and the gap between them is where attackers live.

What This Means for Your Site Right Now

If you've installed any AI-generated plugin in the last six months, or you're running plugins from small developers who lean heavily on AI assistants, the math from Veracode applies to you. Close to half of that code carries an OWASP Top 10 flaw, the case counts are accelerating month over month, and the exploitation window is measured in weeks, not years. Patchstack's tracking of the WordPress security landscape and the Cloud Security Alliance's reporting on the AI-generated CVE surge both point in the same direction: this is a growing category, not a passing scare.

The defensive move is straightforward. Know what's running on your site, know whether it's been reviewed, and check it against what attackers already know how to exploit. You can't fix what you can't see, and the invisible attack surface stays invisible only until someone scans for it. Better that someone is you.

It helps to think about this in terms of provenance rather than trust. You don't need to assume every AI-generated plugin is malicious, because almost none of them are. The author wasn't trying to hurt you. But good intentions don't patch a path traversal bug, and a model that strips a capability check to make a test pass doesn't care whether the developer meant well. The question isn't "do I trust the person who built this," it's "has this code been reviewed by anyone who was looking for security flaws." For a lot of vibe-coded plugins, the honest answer is no, and that's the gap an attacker exploits.

There's also a maintenance dimension that gets overlooked. A plugin from the WordPress.org repository or a serious commercial vendor gets patched when a vulnerability surfaces. A one-off plugin somebody generated for a single site has no update channel, no security mailing list, and no second version coming. When researchers publish a new class of vibe-coded flaw, repository plugins get fixed and pushed out to millions of installs. Your bespoke generated plugin stays frozen exactly as it was the day it shipped, bug and all, until you personally notice and rewrite it. Static code that never gets patched is a liability that only grows with time.

Run a Free WP Vanguard Scan

You don't have to audit every plugin by hand to find the obvious holes. Run a free WP Vanguard scan and let us do the first pass for you. It's genuinely free, there's no signup, and there's nothing to install. WP Vanguard checks your installed plugins and themes against a live vulnerability database, then runs every finding through an AI pass that prioritizes the fixes so you tackle the highest-risk issues first instead of drowning in a flat list of warnings.

That last part matters for vibe-coded plugins specifically. When the database flags something, the AI pass weighs how exploitable it actually is on your setup, so you spend your time on the path traversal that exposes wp-config.php and not on the low-severity notice that can wait. Scan your site in a couple of minutes, see exactly what's exposed, and fix the things that matter before someone else finds them first.

References

• Veracode, AI code security testing (2026).
• Cloud Security Alliance, "Vibe Coding's Security Debt: The AI-Generated CVE Surge" (2026).
• We Watch Your Website, "The Vibe Coding Trap: How AI-Generated WordPress Plugins Are Becoming Attack Vectors."
• Patchstack, "State of WordPress Security in 2026."
• Columbia University research on AI-generated code.