Writing a working WordPress plugin used to require real knowledge. It no longer does, and the plugin ecosystem is absorbing a wave of code written faster than it can be reviewed. If you would rather someone qualified vetted what runs on your site, that is what our security and malware removal service is for.
This is not an argument against AI-assisted development, which is genuinely useful. It is an argument about review. Code that nobody experienced has read is a different risk profile from code that has.
Why This Is a Security Problem
Every plugin you install runs with full access to your site: your database, your files, your users, and anything they submit. A single vulnerable plugin is enough to compromise everything. That has always been true, but the volume of unreviewed code has increased sharply.
Generated code tends to be plausible. It looks like code that works, because it usually does work for the happy path. What it frequently omits is the defensive work that is invisible when everything goes right: capability checks, nonce verification, input sanitisation, and output escaping.
The Patterns That Go Missing
When we review plugin code during audits, the same omissions come up repeatedly.
- Missing capability checks: an admin action any logged-in subscriber can trigger
- Absent nonce verification: forms and AJAX endpoints open to cross-site request forgery
- Unescaped output: user input echoed straight into a page, creating cross-site scripting
- Unprepared database queries: string-concatenated SQL instead of prepared statements
- Over-broad REST endpoints: routes registered with a permission callback that always returns true
- Unvalidated file handling: uploads and file paths accepted without checking type or location
How to Vet a Plugin Before Installing It
Signals Worth Checking
You do not need to read the source to make a reasonable judgment. Check when it was last updated, how many installations it has, whether the developer has other maintained plugins, and whether support requests get answered. A plugin with a real maintenance history is a meaningfully different bet from one published last month by an unknown author.
Questions Worth Asking
Does this plugin need to exist? A surprising amount of functionality people install plugins for is twenty lines in a child theme, or already present in something you run. Every plugin you do not install is a vulnerability you cannot have.
Practical Rules That Reduce Exposure
- Install from the official repository or a known commercial vendor, never from a random download
- Never install nulled or pirated premium plugins, which are a well-established malware vector
- Check the last-updated date before installing, and again periodically afterwards
- Remove plugins you are not using rather than deactivating them, since deactivated code still sits on disk
- Test new plugins on staging before production wherever practical
- Keep a written list of what is installed and why, so nobody has to guess later
Deactivated Does Not Mean Safe
A deactivated plugin still has its files on your server. Depending on the vulnerability, those files can sometimes be reached directly regardless of activation state. If you are not using it, delete it.
If You Do Use AI to Write Site Code
Generated code is a reasonable starting point, not a finished product. Have someone who knows WordPress security review anything that handles user input, touches the database, or registers an endpoint. The review is the part that matters, and it is the part most often skipped.
If you are unsure what is currently installed on your site or who wrote it, a free site audit will give you an inventory and flag the obvious risks.
Get a free audit covering security, updates, backups, and performance gaps. Takes 60 seconds to request and costs nothing.
