If you only have thirty minutes to spend on WordPress security this quarter, spend it on a plugin audit. Plugins are responsible for the majority of WordPress compromises, and most of the risk on most sites is concentrated in a small number of installed plugins that are out of date, abandoned, or simply not needed any more. A focused audit catches all three categories.
This article walks through the audit process we run on every site we onboard, and the criteria we use to decide which plugins stay, which get replaced, and which get removed.
Step 1: Export the plugin list
Start by getting the full list of plugins in front of you in a way you can review. Open Plugins in the WordPress admin. Note every entry, active and inactive. Inactive plugins still sit on disk and can still be exploited. Their files are reachable from the public web. An audit covers both.
For each plugin, record the name, the version installed, the version available, the author, and the date of the last update. Many sites have between 15 and 30 plugins. Write it down.
Step 2: Check the last update date
For each plugin, find its listing on the WordPress.org repository or on the vendor’s site. Look at the last update date. Anything within the last three months is fine. Anything between three and twelve months is worth keeping an eye on but probably acceptable. Anything older than a year is a strong warning. Anything older than two years should be treated as abandoned.
Abandoned plugins are dangerous because any vulnerability published since the last update will never be patched. WordPress.org now flags plugins that have not been updated in a long time, but the responsibility is still on you to read the warning and act.
Step 3: Check the active install count
Plugins with low install counts are riskier in two ways. They tend to be less battle tested, so flaws may not have been spotted yet. And the developer has less commercial reason to maintain them, so updates may be slow. A plugin with one hundred active installs is much riskier than one with one hundred thousand, all else being equal.
This is not a hard rule. Some niche plugins are excellent. But low install plus old last update is a combination that should make you nervous.
Step 4: Check for known vulnerabilities
Several free databases publish WordPress plugin vulnerabilities. The WPScan database and the Patchstack database are the two most widely used. Search for each plugin name. If any vulnerabilities are listed for the version you are running, treat that as urgent.
Wordfence Premium and Solid Security also include vulnerability monitoring and will alert you automatically when a known issue applies to your installed plugins. If you are running a serious site, one of these monitors is worth the subscription.
Step 5: Identify plugin categories with elevated risk
Some categories of plugin have historically had more vulnerabilities than others. File managers, backup plugins, contact form plugins, ecommerce extensions, and SEO plugins all show up disproportionately in security advisories. This is partly because they are the most installed, partly because they handle the most sensitive input, and partly because some of them give administrators dangerous capabilities.
File manager plugins in particular have a long history of remote code execution flaws. A recent Sydney agency we audited had been compromised through a file manager plugin that had been installed and forgotten over a year before. The plugin family has multiple historic critical vulnerabilities. The single most impactful change for that site would have been removing the plugin entirely.
If you do not actively use a file manager plugin in the WordPress admin, remove it. SFTP and your host’s control panel do the same job without the attack surface.
Step 6: Ask whether each plugin is still needed
This is the most underused question in plugin audits. For each plugin, ask honestly whether the feature it provides is still in use. Some plugins were installed for a specific campaign that ended two years ago. Some were installed to fix a problem that has since been solved a different way. Some were installed by a previous developer who is no longer involved.
If you cannot articulate what a plugin does on your site, remove it and see what changes. A staging environment makes this safe. The fewer plugins you run, the less attack surface you have, and the simpler every future update becomes.
Step 7: Consolidate overlapping plugins
Many sites have two SEO plugins active at once, or three caching layers stacked on top of each other, or two different form plugins handling different forms. This is rarely intentional. It builds up over years as different people make different choices.
Pick one. Migrate the work onto it. Remove the rest. The site usually gets faster as a side effect.
Step 8: Score and prioritise
By the end of the audit you should have, for each plugin, a clear judgement. Keep, update, replace, or remove. Prioritise the remove and replace tasks above the routine updates. Anything with a known vulnerability is urgent.
Schedule the work. Backup before each removal. Test the site afterwards. A focused day on a plugin audit, executed properly, can dramatically reduce the risk profile of an inherited WordPress site.
How often should you re audit?
Annually as a minimum. Every six months for an ecommerce site or one that handles sensitive data. After any change of developer or agency, because the new team will have different judgement and may catch something the previous team missed.
Need a hand?
If you would like Smart Coding to run a plugin audit on your WordPress site, give you a written report with our recommendations, and execute the cleanup, get in touch. It is one of the highest impact pieces of work we do.
