There is a persistent belief that WordPress is insecure. The data does not support it, and the shape of the data is more useful than the headline.
Patchstack, which maintains one of the main WordPress vulnerability databases, recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025. Around 91 per cent of them were in plugins and about 9 per cent in themes. WordPress core accounted for six.
Six, in a year, in software running a large share of the web. WordPress itself is not the problem. The things people install into it are.
Why plugins are where the risk lives
WordPress core is maintained by a large security team, reviewed constantly, and patched through an automatic update mechanism that most sites have switched on. A plugin might be maintained by one person in their spare time, or by nobody at all.
That is not a criticism of plugin developers, many of whom do excellent work for free. It is a structural observation. The average site runs somewhere between twenty and thirty plugins, each one written by a different party, each with its own standards, review process and level of ongoing attention. Every one of them runs with the same access to your database as WordPress itself.
Your security is not the security of WordPress. It is the security of the least well maintained thing you have installed.
The categories that carry the most risk
Rather than name individual plugins, which changes month to month and unfairly marks products that have since been fixed, it is more useful to recognise the patterns. These are the characteristics that make a plugin worth a second look.
Anything that accepts input from the public
Contact forms, booking systems, file uploads, comment enhancements, quote calculators. Anything a stranger can interact with without logging in is reachable by an attacker without logging in either.
That does not make them bad, and you obviously need a contact form. It means they deserve the closest attention when updates appear.
Plugins that have stopped being updated
This is the biggest one and the easiest to check. A plugin last updated three years ago is not stable. It is unmaintained. When a vulnerability is found in it, nobody is going to fix it.
The WordPress repository shows a last updated date and the WordPress versions a plugin has been tested against. If a plugin has not been touched in over a year, it belongs on a list to replace.
Enormous install bases
Popularity is not a flaw, and a widely used plugin usually gets more scrutiny and faster fixes. What it does change is the economics for an attacker. A vulnerability in something installed on a million sites is worth building an automated scanner for. A vulnerability in something installed on two hundred sites is not.
The practical consequence is speed. When a serious flaw is disclosed in a very popular plugin, mass scanning starts almost immediately, and the window between disclosure and attempted exploitation is measured in days rather than months.
Nulled and pirated premium plugins
This one is not a risk pattern so much as a guaranteed outcome. A paid plugin distributed free from an unofficial site has been modified by whoever is distributing it, and they are not doing it out of generosity. The backdoor is the product.
If a plugin arrived from anywhere other than the WordPress repository or the developer directly, treat the site as already compromised.
Premium plugins generally
Paid does not mean safer. In the same 2025 dataset, 29 per cent of reported vulnerabilities involved premium or freemium components, and around three quarters of those were considered exploitable in real attacks.
Premium plugins also introduce a licensing problem. When a licence lapses, updates stop, and a site can sit for a year on a version with a known flaw purely because a renewal was missed.
The number that should worry you most
Of those 11,334 vulnerabilities disclosed in 2025, 46 per cent had no patch available at the time they were made public.
Read that again, because it undermines the usual advice. Keeping everything updated is necessary, but for nearly half of disclosed vulnerabilities there was nothing to update to. The flaw was public and the fix did not exist.
That is the entire argument for having something in front of the site as well as keeping it current. A firewall that blocks the exploit pattern protects you during the window where updating cannot, because there is nothing to install.
How to audit what you have
This takes about twenty minutes and does not require any tools beyond your own dashboard.
- Open Plugins and count them. If the number surprises you, that is the finding
- Deactivate and delete anything not actively doing a job. Deactivated is not enough, the code is still on the server
- For each remaining plugin, check when it was last updated. Over a year is a replacement candidate
- Identify anything the public can interact with and note it as needing prompt updates
- Confirm every premium licence is current, because a lapsed one silently stops updates
- Confirm nothing was installed from outside the repository or the developer
Deleting unused plugins is the highest value item on that list and the one most often skipped. An unused plugin has the same vulnerabilities as a used one, and deactivating it does not remove the files from the server.
What this adds up to
WordPress is not the weak point. The plugin you installed once for a job that finished two years ago is. Vulnerability disclosures rose 42 per cent in 2025 and high severity findings more than doubled, so the plugin list you set and forgot is not the plugin list you have. Keeping it reviewed, patched and shielded is what our WordPress security and plugin maintenance work covers.
