In August 2026 a widely used forms plugin was publicly accused of adding a backdoor to new installations. Whatever the eventual conclusion, the episode made a point worth keeping: plugin trust is not a decision you make once. It is a supply chain you are exposed to continuously.
The average WordPress site runs twenty to thirty plugins. Each one is code you did not write, updating automatically, with database and file access. Outdated and compromised plugins cause far more real incidents than WordPress core ever has. Here is how we assess one before it goes near a client site.
Seven signals, in the order we check them
1. Last updated, against the current WordPress version
The directory shows a tested up to value. If a plugin has not been touched in over a year, or was never tested against the current major release, that is not automatically fatal for a simple plugin, but it is a strong signal for anything complex. Abandoned code does not receive security patches.
2. Who actually owns it now
This is the one most people skip and it is where the recent problems come from. Popular plugins get acquired, and the new owner may have a different business model: injecting affiliate links, adding telemetry, or monetising an install base that trusted the previous developer.
Check the plugin changelog and the support forum for any ownership announcement. A sudden change of tone, a new upsell layer, or a burst of one star reviews after years of five is usually the visible edge of a change of hands.
3. Open support threads
Go to the support tab and sort by unresolved. Look at how many threads have no developer reply in the last month. A plugin with two hundred thousand installs and no answered threads is effectively unmaintained regardless of what the update date says.
4. Known vulnerabilities
Search the plugin name in a vulnerability database before installing. The GitHub Advisory Database and Patchstack both index WordPress plugin issues. A history of disclosed vulnerabilities is not disqualifying by itself, since being audited is a sign of relevance. What matters is how fast they were patched.
5. Whether it needs to exist
The safest plugin is the one you do not install. A surprising number of plugins do something a theme function, a block, or ten lines of CSS could do. Every install is a permanent addition to your attack surface and your update testing burden.
6. What it wants access to
Does a contact form plugin need to phone home? Does an image optimiser need to create admin users? Read the privacy notice, and after installing, check whether new scheduled tasks or outbound requests appeared.
7. Where you are downloading it from
Only the official WordPress plugin directory or the developer own site. Nulled premium plugins from download sites are the single most common source of compromise we find on rescued sites, and the malware is usually in the very file that makes the licence check pass.
Auditing what is already installed
Vetting new plugins does nothing about the twenty five already running. Do this once, then quarterly.
- List every active plugin and write down, in one line, what it does for the business. Anything you cannot justify comes off.
- Delete deactivated plugins rather than leaving them. Inactive plugin files are still on disk and still exploitable.
- Check each remaining one against a vulnerability database.
- Confirm every premium plugin has a valid licence that can actually receive updates. A premium plugin that cannot update is a nulled plugin or an expired one, and both are liabilities.
- Note which plugins have not been updated in over a year and start planning replacements.
What to do when a plugin you use is accused
Do not panic delete. Do not immediately update either, since if a bad release is the issue, updating makes it worse.
Pin the current version, read the developer response and at least one independent analysis, and check whether your installed version is the affected one. If you have a staging site, test the new release there. If the plugin is genuinely compromised, replacing it is a project, and rushing it at four in the afternoon is how sites break.
Our maintenance checklist includes the quarterly plugin audit, and if you suspect something is already wrong, start with the hacked site cleanup process.
Frequently asked questions
How can I tell if a WordPress plugin is safe?
Check the last updated date against the current WordPress version, read unresolved support threads for developer responses, search the plugin name in a vulnerability database such as the GitHub Advisory Database or Patchstack, confirm current ownership through the changelog, and download only from the official directory or the developer site.
How many plugins is too many for a WordPress site?
There is no fixed number, since ten badly written plugins are worse than thirty good ones. The practical test is whether you can state in one sentence what each plugin does for the business. Anything failing that test is adding update testing burden and attack surface for nothing.
Are nulled or cracked WordPress plugins dangerous?
Yes, and predictably so. The licence check has to be bypassed, which means the file was modified by someone with no accountability to you. In practice that modification frequently includes a backdoor, and it is the most common single cause of compromise we encounter on sites we are asked to rescue.
Should I delete deactivated plugins?
Yes. Deactivating removes the plugin from execution but leaves the files on the server, where certain vulnerability classes can still be reached directly. If you are not using it, delete it. If you might need it later, you can reinstall it in under a minute.
What should I do if a plugin I use is reported as compromised?
Do not update immediately, since if a specific release is the problem, updating may install it. Confirm which versions are affected, check yours, read the developer response alongside at least one independent analysis, and test any new release on staging first. Then plan a replacement if the concern is credible.