How to audit a WordPress plugin before installing it

There’s a call that anyone who maintains WordPress sites has gotten at some point: “Google is showing my site with Japanese titles and casino ads.” Often the culprit is a plugin installed months earlier, sometimes one with thousands of installs and good ratings, that had an unpatched vulnerability or an outright backdoor.

Cleaning up a site like that costs hours of emergency work and, above all, trust. That’s why we don’t install any plugin on a live site without running it through an audit protocol first.

The official WordPress repository has tens of thousands of plugins. Many are excellent, some are dangerous and most are mediocre. Telling them apart before you install is essential.

Why plugins are a special risk

WordPress runs plugin code with the same privileges as the core. A plugin can:

• Read and modify any data in the database.
• Send data to external servers without your knowledge.
• Inject code into the frontend to steal user information.
• Create hidden admin users.
• Download and install more malware if it’s part of an infection chain.

On top of that, there are performance risks (plugins that slow down every page), compatibility risks (conflicts with other plugins or the theme) and maintenance risks (abandoned plugins that stop working with WordPress updates).

Auditing before you install doesn’t guarantee there won’t be problems, but it eliminates most of the obvious risks.

Phase 1: evaluation in the repository (before downloading)

Before touching the code, we review the plugin’s public information:

Last update. A plugin that hasn’t been updated in over a year is suspicious. We prefer plugins updated within the last 3 to 6 months.

Compatibility with your WordPress version. If the plugin says it has only been tested up to a version from several years ago, there’s a risk of incompatibilities. It’s not an automatic veto, but it is a warning sign.

Number of active installations. More installs usually mean more eyes reviewing the code. Our rule: below 1,000 active installs, the plugin needs a deeper code review; below 100, we’re wary unless it comes from a known developer. Keep in mind that popularity isn’t a guarantee either: the most installed plugins are also the most attractive to attackers.

Vulnerability history. We check public databases such as those from WPScan, Patchstack or Wordfence. Having had vulnerabilities doesn’t rule a plugin out (it happens to almost all the big ones); what matters is how long they took to fix. And if the plugin’s page shows as closed in the repository, don’t install it until you know why: WordPress.org closes plugins for, among other reasons, unresolved security issues.

Reviews and support. We read recent negative reviews and open support threads. A plugin with lots of “it broke my site” or “support never answers” is a red flag, whatever its average rating.

Developer. Is it an established company or an unknown developer? Do they have other well-regarded plugins and a clear way to get in touch?

If it fails several of these criteria, we don’t even download the code: there are alternatives for almost everything in WordPress.

Phase 2: code analysis (for new or less proven plugins)

For plugins that pass phase 1 but are critical to the project or come from less known sources, we review the code. You don’t need to be a PHP expert to spot the most obvious issues:

Dangerous functions. We look for eval(), exec(), shell_exec() or base64_decode(). Their presence doesn’t mean the plugin is malicious, but it needs a justification. An SEO plugin that uses eval() is suspicious.

External calls. We look for wp_remote_get(), wp_remote_post(), file_get_contents() with URLs, or curl. Which servers does it connect to? A forms plugin that sends data to a domain unrelated to the service is a red flag.

User or role creation. Does it create admin users? Does it add new capabilities? That can be legitimate (in a membership plugin, for example), but it has to match what the plugin does.

Obfuscated code. Obfuscated or base64-encoded code with no apparent reason. Some premium plugins do this to protect themselves; in a free one, it’s a warning sign.

File writes. Does the plugin try to modify WordPress core files or theme files? That’s rarely necessary and a classic infection vector.

In this phase we combine automated tools, such as the official Plugin Check plugin or PHP_CodeSniffer with the WordPress Coding Standards rules, with a manual review of the main files.

Phase 3: testing in an isolated environment

We never install a plugin straight onto a live site. The workflow looks like this:

1. Local installation. We install the plugin in a local development environment (Docker, LocalWP or similar).
2. Basic functionality test. Does it do what it promises? Are settings saved correctly?
3. Resource usage. With Query Monitor or a similar tool, we check whether it adds database queries, loads unnecessary scripts on every page or uses too much memory.
4. Conflict testing. With the site’s main plugins already installed, we make sure there are no JavaScript errors, broken features or PHP warnings.
5. Basic security review. Does it escape output properly? Does it validate and sanitize input? Does it use nonces and check permissions in its forms and AJAX requests?

Only once the plugin passes all these phases do we move it to staging and, finally, to production. If it affects performance, also check how it plays with your cache: we explain that in how to set up caching in WordPress correctly.

Premium plugins: additional considerations

Paid plugins have their own rules:

Licensing and activation servers. Some premium plugins need to connect to the developer’s license server to work or update. If the developer shuts down, what happens to your plugin?

Updates. Premium plugins aren’t updated through the official repository but through the developer’s own system, usually tied to an active license. If the license expires, you stop getting security patches.

Closed code. Some premium plugins have obfuscated code or code encrypted with tools like ionCube, which makes a full audit impossible. In that case, you depend entirely on the developer’s reputation.

“Nulled” copies. Pirated versions of premium plugins that circulate for free online are one of the most common infection vectors. No savings are worth that risk.

Here the developer’s track record matters even more: we prefer companies with years in business over “lifetime” licenses from newcomers.

Red flags that automatically disqualify a plugin

Some signs, if they show up, rule a plugin out instantly, no further audit needed:

• Obfuscated code in a free plugin.
• Calls to suspicious domains or domains that change between versions.
• Creation of hidden admin users.
• Content injected without consent (for example, hidden affiliate links).
• User input reaching SQL queries without validation.
• More than 2 years without updates and incompatibility with current WordPress versions.
• A developer with no contact details or verifiable identity.

Maintenance after installation

A plugin that’s secure today may have a newly discovered vulnerability tomorrow. That’s why:

• We keep an inventory of every installed plugin and its version.
• We subscribe to security alerts (Wordfence, Patchstack, WPScan or similar).
• We apply security updates within 24 to 48 hours.
• Every quarter, we check whether all installed plugins are still needed.

And plugin security doesn’t do much good if access to the dashboard is weak: passwords, 2FA and password managers are the other half of the job.

Frequently asked questions

How long does it take to audit a plugin?

Phase 1 takes about 5 minutes. Phase 2, from 15 to 30 minutes for simple plugins. Phase 3 depends on complexity. For repository plugins with over 1 million installs and a good track record, phase 1 plus a staging test is sometimes enough.

Should I avoid free plugins?

No. Many free plugins in the official repository are excellent and maintained by professional teams (Yoast SEO or WooCommerce, for example). Being free isn’t the problem; being abandoned is.

Can I trust plugins from CodeCanyon or similar marketplaces?

With more caution. They don’t go through the same review as the official repository, so they require a deeper audit. Whenever we can, we buy directly from the developer.

What if I already installed a plugin without auditing it and now I’m having problems?

Uninstalling isn’t always enough. Some plugins leave behind residual code, database tables or user accounts. Check what changed, clean up what it left behind and consider a full security audit. If there are already signs of a hack, follow this first aid guide for a hacked website.

Conclusion

The plugin ecosystem is one of WordPress’s greatest strengths and also one of its biggest risks. Installing takes a single click, and that hides what you’re allowing to run on your server.

An audit protocol isn’t paranoia, it’s professionalism. It takes minutes and can save you hours of cleanup or the damage to your reputation that a hack leaves behind.

If you manage WordPress sites and want us to review the plugins you have installed, or you need help cleaning up a compromised site, tell us about your case. That said, we’d rather help you prevent the problem than fix it afterward.