**Security Advisory | We Watch Your Website**
 
 

The calls started coming in before the coffee cooled.
 
A WordPress site owner — developer by trade, not by security background — had used an AI assistant to build a custom plugin over a weekend. It handled contact form submissions, wrote data to a database, and passed a few basic functionality tests. It worked. They shipped it. Three weeks later, their site was serving malware to visitors.
 
This is not an isolated case. We are now seeing a measurable and accelerating pattern: AI-generated (“vibe coded”) WordPress plugins are being exploited within weeks of deployment, often before the site owner even knows the plugin has a problem.
 
 

The False Confidence Loop

 
AI coding assistants are genuinely impressive. They can scaffold a working WordPress plugin in minutes. The output *looks* like real code. It follows familiar patterns. It runs without errors.
 
But “working” and “secure” are not the same thing.
 
Security vulnerabilities are not syntax errors. A plugin can function perfectly — accepting input, querying a database, returning responses — while simultaneously being riddled with SQL injection points, missing nonce verification, broken access controls, or path traversal vectors. AI models optimize for functionality. They are trained on vast repositories of code that includes, frankly, a lot of insecure code. Without explicit, adversarial security review, vulnerabilities ship.
&nbps;
The developer sees a plugin that works. They gain confidence. They deploy it. And that’s where the loop closes — because attackers are watching.
 
 

“But My Server Blocks Directory Enumeration”

 
This is the most common misconception we hear when site owners try to understand how their plugin was found and targeted.
 
Nginx rules and `.htaccess` directives that disable directory listing are good hygiene. They are not a shield.
 
Attackers don’t need a directory listing to find your plugin. They have several other avenues:
 
Predictable file paths. Every WordPress plugin follows a known structure. Automated scanners probe paths like `/wp-content/plugins/your-plugin-name/readme.txt` or known asset filenames. A 200 response confirms the plugin’s presence. This takes seconds at scale.
 
Page source enumeration. WordPress plugins routinely enqueue JavaScript and CSS files. Those asset URLs — including the plugin name and often the version — appear directly in your page’s HTML source. Anyone who views source on your homepage sees your plugin list.
 
Public discussion. If the plugin was ever mentioned in a blog post, a GitHub repository, a forum thread, or even a client invoice, automated OSINT tooling can find it and map it to known vulnerability databases.
 
Shodan and passive scanning. Large portions of the internet are continuously indexed. Attackers don’t scan your site — they query databases of what’s already been scanned.
 
The bottom line: if a vulnerable plugin is running on a live WordPress site, assume it will be found. The question is not *if* but *when* — and for novel vulnerabilities in freshly deployed code, the window can be surprisingly short.
 
 

What We’re Seeing in the Wild

 
At We Watch Your Website, we monitor and protect over 2 million WordPress sites globally. Over the past several months, we have observed a clear uptick in compromises tracing back to custom or lightly-reviewed AI-generated plugins.
 
The vulnerability classes are not exotic. They are the same classes that have plagued WordPress for fifteen years:
 

• SQL injection via unsanitized POST parameters passed directly to `$wpdb->query()`
• Missing nonce verification on AJAX handlers, enabling CSRF-driven data manipulation
• Broken access controls subscriber-level users reaching admin-only functionality because capability checks were omitted or implemented incorrectly
• Arbitrary file read/write via path traversal in file handling routines
• Reflected cross-site scripting from unescaped output

 

AI assistants often generate code that *resembles* secure patterns without actually implementing them correctly. A `prepare()` statement used with the wrong placeholder type. A nonce check present on page load but absent on the AJAX endpoint. A capability check that evaluates to true for all authenticated users.
 
These are not bugs a functionality test catches. They require adversarial analysis.
 
 

We Put Our Analyzer to the Test

 
We developed our plugin vulnerability analyzer pipeline specifically to address this gap — automated, adversarial static analysis of WordPress plugin code, powered by multi-stage taint tracing and AI-assisted vulnerability classification.
 
To validate our detection rates, we ran our analyzer against a set of plugins with known, confirmed CVEs as well as a control group of well-maintained plugins with clean security records.
 

Confirmed Vulnerabilities Detected (100% Detection Rate)

 

Plugin	CVE	Vulnerability Class	Result
Pojo Accessibility	CVE-2026-2413	Broken Access Control	⚠ Detected
WPCargo Track & Trace	CVE-2021-25003	Arbitrary File Write / RCE	⚠ Detected
Ninja Forms	CVE-2022-34627	SQL Injection	⚠ Detected
Tutor LMS	CVE-2022-45083	Privilege Escalation	⚠ Detected
Detection Rate			100%

 
Our analyzer identified the vulnerable code paths, traced the taint flow from user input to dangerous sinks, and produced actionable findings for every confirmed CVE in this test set.
 

Clean Plugins — No False Positives

 

Plugin	Active Installs	Result
Yoast SEO	10M+	✔ Clean
Wordfence Security	4M+	✔ Clean
Jetpack	4M+	✔ Clean
WooCommerce	5M+	✔ Clean

 

Precision matters as much as recall. A security tool that generates noise gets turned off. Our clean results on widely-audited, production-grade plugins confirm that our analyzer is not producing false positives at scale.

 
 

The Recommendation

 
If you or your team has deployed a custom WordPress plugin — AI-assisted or otherwise — that has not undergone formal security review, treat it as potentially vulnerable until proven otherwise.
 
Before your next plugin goes live, we recommend:
 

1. Automated static analysis — taint tracing, AJAX endpoint auditing, capability check verification
2. Manual code review of any handler that touches `$_POST`, `$_GET`, or the filesystem
3. Server-side monitoring for anomalous behavior post-deployment

 
 
We Watch Your Website offers plugin vulnerability analysis through our analyzer pipeline. To have your plugin reviewed, contact us directly at [traef@wewatchyourwebsite.com](mailto:traef@wewatchyourwebsite.com). You’ll receive a detailed findings report covering vulnerability class, affected code path, severity rating, and remediation guidance.
 
Building with AI is not the problem. Shipping without review is.
 

We Watch Your Website has protected over 3 million WordPress sites since 2007. Our threat intelligence database covers 300,000+ malware samples, and our detection pipeline consistently identifies emerging threats an average of 33 days ahead of public blacklists.