How to Audit WordPress Plugins for Security Risks

WordPress core is rarely how a site gets broken into. The usual route is a plugin: one that stopped receiving fixes, one that was pirated, or one written in a hurry for a single feature and never reviewed. A WordPress plugin security audit is the routine that finds those before someone else does.

You list what is installed, ask the same few questions of each item, and decide whether it stays, gets replaced or goes.

Build the inventory first

The Plugins screen shows active and inactive plugins. Look at the filter links above the list as well: "Must-Use" and "Drop-ins" appear only when such files exist, and they load without ever showing an Activate link. With WP-CLI, one command gives you most of what the audit needs:

wp plugin list --fields=name,status,version,update,auto_update,wporg_status,wporg_last_updated
wp plugin list --status=must-use
wp theme list

The wporg_status column says whether a plugin is still listed in the WordPress.org directory, and wporg_last_updated gives the date of its last release there. Plugins with nothing in those columns did not come from the directory. They are commercial plugins or custom code, and you check them by hand.

Put the list in a spreadsheet and add three columns of your own: what the plugin is for, who asked for it and where it was downloaded from. A plugin nobody can explain is the first candidate for removal.

Signs that a plugin has been abandoned

Open each plugin's page on WordPress.org and read the details panel. A "Last updated" date more than a year or two back is a warning. So is the banner that says the plugin has not been tested with the last three major releases of WordPress.

A closed plugin is more serious. Its page says it is no longer available for download, sometimes with a reason. Your site keeps running the installed copy and simply never sees another update, and the Plugins screen may give no hint of it. If the stated reason is a security issue, deactivate and remove the plugin now and look for a replacement afterwards.

For commercial plugins, read the changelog on the vendor's site and check that the license is still valid. An expired license means updates have stopped arriving, which turns a maintained plugin into an unmaintained one on your site alone.

Age is not everything. A fifty-line plugin that registers one shortcode can go years without needing a change. A form builder that accepts file uploads cannot.

Check each version against known vulnerabilities

Several organizations publish searchable records of WordPress plugin vulnerabilities, among them WPScan, Patchstack and Wordfence. Each record names the plugin, the affected versions and the version that contains the fix, often with a CVE identifier.

For every plugin on your list, compare the installed version with those records and sort the results:

• Fixed in a later version: update, after a backup and ideally on staging first.
• No fix available: deactivate it and plan the replacement.
• Exploitable without logging in: treat as urgent, whatever the score next to it.
• Requires a logged-in user: less urgent on a brochure site where only staff have accounts. On a store, a membership site or an LMS, every customer and learner is a logged-in user, so the bar is much lower than it sounds.

Doing this by hand every week is unrealistic. Most security plugins and several hosting dashboards compare your installed versions with one of these databases and send an alert. Site Health does not, so do not read its green ticks as a clean result.

Pirated and repackaged plugins

"Nulled" plugins are paid plugins with the license check removed, offered as free downloads. They are a frequent source of infections on sites we are asked to clean. The copy often carries added code that creates a hidden administrator, injects spam links or redirects visitors, and it will never receive a security update.

For plugins from the WordPress.org directory, wp plugin verify-checksums --all compares the files on your server with the official release and reports any that differ. For a commercial plugin, download a fresh copy of the same version from the vendor and compare the two folders. If any plugin on the site came from an unofficial source, delete it and buy a license or choose an alternative.

Look at what each plugin can reach

WordPress has no permission system for plugins. Every active plugin runs with full access to the database and to any file PHP can touch. The useful question is therefore what each plugin opens up to other people:

• Roles and capabilities. Has it added user roles, and what can they do? Check its settings for options such as who may upload files or publish from the front end.
• Public entry points. Forms, AJAX actions and REST API routes that work without a login deserve the most attention. Visiting /wp-json/ lists the route namespaces your plugins have registered.
• Uploads from visitors. Which file types are accepted, and where are they stored?
• Outside connections. Which services does it send data to, and whose API keys are saved in its settings?

Be strict with administration tools. File managers, database browsers, migration plugins and debugging tools give anyone who reaches the dashboard direct access to files or data. Install them when you need them and delete them the same day.

Remove, replace or keep

Deactivating is not removing. A deactivated plugin's files stay on the server and can still be requested by their address, so delete what you are not using. Test on staging first when pages depend on the plugin's shortcodes or blocks, because removing it leaves raw shortcode text behind.

Look for overlap as well. Two SEO plugins, three security plugins or a page builder kept alive for a single old landing page each add code to maintain for no gain. After removing something, check whether it left behind user roles, scheduled tasks or database tables that also need to go.

Reviewing custom and one-off code

No vulnerability database covers the plugin a freelancer wrote for you some years ago, the snippets pasted into functions.php or the entries in a code-snippets plugin. Those need a person to read them. The points below catch most problems:

• Every action that changes data checks who is asking with current_user_can() and verifies a nonce with check_admin_referer(), check_ajax_referer() or wp_verify_nonce().
• Handlers registered on wp_ajax_nopriv_ hooks, and REST routes whose permission_callback is __return_true, are open to everyone. Confirm that each one is meant to be.
• Database queries that include request data go through $wpdb->prepare().
• Output is escaped with esc_html(), esc_attr(), esc_url() or wp_kses_post(), and input is cleaned with functions such as sanitize_text_field() and absint().
• File uploads go through wp_handle_upload() with a restricted list of types.
• There is no eval(), no unserialize() on request data and no password or API key written into the code.

The security section of the WordPress developer handbook explains each of these. The Plugin Check tool from WordPress.org automates part of the review. It catches patterns such as missing escaping, but it cannot tell you that an endpoint should have required a login, which is the mistake that matters most.

Make the WordPress plugin security audit a routine

Repeat the audit every quarter, and ask the same questions before any new plugin is installed. Who maintains it, when was it last updated, what does it expose, and do we already have something that does this?

The inventory, the checks against the directory and the removals are work a site owner can do. Code review is not, and neither is replacing an abandoned plugin that holds years of data. We build and maintain our own plugins, so we know how much of a plugin's safety lies in details nobody sees from the dashboard. When the audit ends with a list of custom code to review or several small plugins that would be safer as one maintained piece of code, that is a job for WordPress plugin development. Keeping the whole set updated and monitored afterwards belongs in a WordPress maintenance plan. If the audit leaves you weighing a rebuild, read the signs that you need a custom plugin next.

Frequently asked questions

How many plugins is too many?

There is no number. Ten poorly maintained plugins are a bigger risk than forty good ones. What counts is whether each plugin has an active maintainer, a reason to be there and someone on your side who would notice if it stopped being updated.

Are paid plugins safer than free ones?

Not by default. A paid plugin usually has funded support and a team behind it, which helps. Its code is also seen by fewer outside reviewers than a popular free plugin. Judge both the same way: update history, how quickly past vulnerabilities were fixed and how openly the vendor reported them.

Does deactivating a vulnerable plugin make the site safe?

It helps, because WordPress no longer loads the plugin's code. The files remain on the server, though, and some can still be requested directly. Delete the plugin once you have confirmed nothing depends on it.

What should I do when a plugin I rely on is closed?

Find out why from the notice on its WordPress.org page and from the author's own site. If the reason is a security issue with no fix, deactivate it. Then look for a maintained alternative that can import the old plugin's data, and test the switch on staging before touching the live site.