WordPress vulnerabilities: 11,334 per year, with the server blocking 12 per cent of them

In the WordPress world, 11,334 new vulnerabilities were disclosed in 2025 — 42 per cent more than the previous year. Of these, 91 per cent were in plugins and six were in the WordPress core. However, one figure is even more significant: server-side security measures blocked 12 per cent of attacks targeting WordPress. This article explains what these figures mean for a typical business website and what you can do about them yourself.

Figures

Patchstack maintains a database of WordPress vulnerabilities and publishes an annual report on them. Figures for 2025:

Observation	Chapter
New vulnerabilities	11,334 (+42% compared to 2024)
Share in add-ons	91 %
Share in themes	9 %
At the heart of WordPress	6 items, low priority
Classified as serious	1 966 (17 %)
No corrections at the time of publication	46 %
Median time to mass adoption	5 hours
Attacks thwarted by server security measures	12 %

One comparison helps to put things into perspective: more serious vulnerabilities were found in 2025 than in the previous two years combined.

What these figures do not mean

There are three misconceptions that should be cleared up straight away, as they lead to the wrong decisions.

1. WordPress itself is not insecure

Six vulnerabilities were found in the core, all classified as low — out of 11,334. The problem isn’t WordPress itself, but what is installed on top of it. So changing the platform won’t fix anything if the same number of third-party plugins are installed on the new platform.

2. A vulnerability does not mean a breach

Most vulnerabilities require a logged-in user or some other condition to be exploited. Seventeen per cent were serious enough to be exploited in automated, large-scale attacks. That still amounts to 1,966 cases per year.

3. The server does not protect you

This is where many people put their trust in the wrong thing. When a hosting service advertises a firewall and malware protection, the assumption is that it will take care of the matter. In Patchstack’s test, traditional security measures blocked 12% of WordPress-specific attacks and 26% of all attacks.

The reason is structural: the firewall recognises the form of the attack, but the vulnerability in the add-on appears to be a normal request. The only sure fix is an update.

Why five hours is an important figure

For the most widely exploited vulnerabilities, the median time from disclosure to mass exploitation was five hours. Around half of the serious ones were exploited within 24 hours.

This leads to one practical conclusion, which is the most important point of the whole article: a monthly update is not enough. If updates are carried out once a month, the site will have a known vulnerability for an average of two weeks. The attack is not targeted — a bot scans all sites that match a known fingerprint.

Furthermore, 46 per cent of the vulnerabilities were disclosed without a fix being available. In such cases, even updating doesn’t help, and the only option is to disable the plugin until a fix becomes available. This requires someone to monitor the situation.

What you can check for yourself today

These don’t require any purchases or technical expertise. Log in to your WordPress dashboard and go through the following:

• Count the add-ons. The ‘Add-ons’ page shows the number. Each one is a piece of code maintained by someone else. The risk is directly proportional to the number.
• Look for those that haven’t been updated for a year. The plugin page will say ‘last updated’. More than a year without an update effectively means the plugin has been abandoned — remove it.
• Remove them completely. A deactivated plugin is still on the server, and some vulnerabilities remain active even then. Remove them; don’t just deactivate them.
• Check user accounts. There should be no accounts on the Users page that you do not recognise. Remove the administrator accounts of former contributors.
• Make sure that a backup exists and can be restored. Ask your provider when the restoration process was last tested. A backup that has never been restored is, by definition, not a backup.
• Enable automatic updates, at least for security updates. There is a risk of the site breaking, but it is smaller than the risk of it remaining vulnerable for weeks.

If you go through this list, you’ll have done most of what’s involved in an audit.

What else is checked during an audit?

The rest are things that aren’t visible in the admin panel:

• Are there any known vulnerabilities in the installed versions? — This is checked against a database, not by visual inspection
• Are there any files left on the site that don’t belong there?
• PHP version and server settings
• login security and file permissions
• Which add-ons can be removed entirely without anything breaking — this is usually the aspect that reduces the risk the most

We charge a one-off fee of €690 (0% VAT) for an audit, which provides you with a written list of issues to be rectified, prioritised by importance. If the site is in good order, we’ll say so — in which case the list will be quite short.

In demand

How many add-ons are too many?

There’s no exact cut-off point, as plugins vary enormously. A useful rule of thumb: every plugin should do something you can name. If you can’t say what one of them does, it’s a candidate for removal. A standard business website requires fewer add-ons than most actually have.

Is a security plugin enough?

It helps with certain issues — login restrictions and the detection of known malicious code. However, it does not fix a vulnerability in another plugin, and it is itself a plugin — that is, code which may have its own vulnerabilities. Updating is always the primary measure; security measures are secondary.

How do I know if my website has already been hacked?

The most common signs: search results show pages you haven’t created; the site redirects visitors elsewhere, but only on mobile devices or only when they arrive via search results; there is an unknown administrator on the user list; your emails start ending up in spam. However, some breaches are not visible from the outside at all, as the intention is to use the server for other purposes.

Is WordPress less secure than other platforms?

There are more vulnerabilities to be found, but the main reason is scale: WordPress is by far the most widely used platform, so it is also the most thoroughly examined. A discovered vulnerability is a sign that someone was looking for one. A more significant difference is that WordPress’s extensibility is open — this is both its strength and the subject of this article.