Single Blog

WordPress Vulnerability Disclosures Hit 11,334 in 2025

September 2, 2026, Written by 0 comment

Patchstack recorded 11,334 new vulnerabilities across WordPress core, plugins and themes in 2025, a 42% increase on 2024. We charted this trend in March 2024 when the line was already going one way. Here are the annual figures since then.

Bar chart of new WordPress vulnerabilities disclosed each year: 1,382 in 2021, 4,528 in 2022, 5,948 in 2023, 7,966 in 2024, and 11,334 in 2025. Source: Patchstack, State of WordPress Security 2022–2026.
Year New vulnerabilities
2021 1,382
2022 4,528
2023 5,948
2024 7,966
2025 11,334

All five figures come from Patchstack’s annual State of WordPress Security reports, so it is the same source across the series. Patchstack sells WordPress security software. Their reports are the most complete public dataset available, and they come from a vendor with an interest in the finding.

What the Count Does and Doesn’t Measure

A disclosure count is a count of problems that were found, reported and written up. It is not a count of sites that were broken into. Part of the rise is more researchers looking, more bug bounty programmes paying, and better tooling for finding flaws.

The split has not changed much. Of 2025’s total, 91% were in plugins and 9% in themes. Six were in WordPress core.

That split is the practical point for a business site. The risk on a WordPress site tracks the number of plugins installed and who maintains them, not the WordPress brand. A site running twelve plugins from active vendors is in a different position to one running thirty-five, several of which have not shipped an update in two years.

What 2026 Looks Like So Far

Patchstack’s next annual report is not due until early 2027, so we went to the underlying public record instead. The CVE Program publishes its full list of CVE records as open data, updated continuously. Patchstack, WPScan and Wordfence are all CVE Numbering Authorities whose remit is the WordPress ecosystem, so counting the records those three assigned — plus any other record naming WordPress — gives a monthly series that runs right up to last week.

Bar chart of WordPress CVEs published each month from January 2021 to August 2026, rising from under 100 per month in 2021 to roughly 900–1,400 per month through 2025 and 2026, with the 2026 months level against 2025 rather than continuing to climb.

On that basis:

Period WordPress CVEs published
2024 8,892
2025 11,066
2026, January to August 7,444

2026 is averaging 931 a month. Held to that rate it lands around 11,200 for the year, against 11,066 in 2025. On this measure 2025 was up 24% on 2024; 2026 is tracking level. The run of record years has paused.

Four caveats on that chart, because this is a run-rate estimate rather than a final figure.

The climb from 2021 to 2023 partly reflects Patchstack and Wordfence scaling up their own CVE programmes rather than a fourfold increase in flaws, so 2024 onward is the stretch closer to like-for-like. Records are also published late and keep filling in, so 2026 will edge up rather than down.

Publication is lumpy. CVE Numbering Authorities file in batches, and WPScan published more records in July and August 2026 than in the previous six months combined. Month-to-month spikes are often a filing schedule rather than a disclosure surge.

The mix has shifted underneath the total. Against 2025, Patchstack’s assignments are running about a fifth lower this year while Wordfence and WPScan are up. The total is level, but it is level for compositional reasons, not because each contributor held steady.

And these counts are not Patchstack’s counts. The two track different things and should not be read against each other, which is why they are on separate charts here.

Roughly 900 new WordPress vulnerabilities a month is the current baseline, and it is holding.

The Number That Changed the Job

Two figures in Patchstack’s 2026 report matter more than the headline count.

The first is the gap between disclosure and attack. Patchstack put the weighted median time to first exploitation at five hours. 20% of vulnerabilities were exploited within six hours of disclosure, 45% within 24 hours, and 70% within seven days.

The second is that 46% of 2025’s vulnerabilities had no patch available at the point they were made public. For close to half of them, the update you would install did not yet exist.

Even a same-day patching routine sits on the wrong side of a five-hour median, and for the unpatched half there is nothing to install regardless of how fast you are.

Three Core Security Releases in 2026

Six core vulnerabilities in 2025 is in line with previous years. 2026 has not followed that pattern. WordPress shipped three core security releases between 17 July and 12 August — 7.0.2, 7.0.3 and 7.0.4 — including an unauthenticated remote code execution chain that WordPress.org considered serious enough to force auto-updates across affected sites.

The other shift is in how malicious code arrives. In April 2026 a plugin author’s portfolio was used to push a backdoor through the official update channel, and a separate vendor’s premium update server was breached the same week. A third vendor’s paid builds were compromised in May and June. In each case the update itself was the delivery mechanism.

That does not make updating optional. It does mean plugin ownership changes and vendor build pipelines are now part of what has to be watched.

How We Handle It

Our sites run Patchstack, which applies a virtual patch at the firewall for a known vulnerability whether or not the vendor has shipped a fix. That is the layer that covers the hours between disclosure and update, and the unpatched half where no update is coming.

Plugin and theme updates are applied by hand on a regular cadence across most of the sites we manage, with a staging check first on anything complex. Core security releases we verify individually rather than assume the automatic update fired — it can be silently disabled by a config constant or a leftover version-control folder.

We also raise plugin count with clients when it drifts. Auditing what is installed and removing what nothing depends on is usually the first thing we do on a site we take over.

Self-Managed Sites

Check Dashboard → Updates and confirm you are on the current WordPress release. Then open Plugins and look at the “last updated” date on each one — anything not touched in over a year is worth replacing or removing.

If you are relying on updates alone, a virtual patching layer is the gap worth closing. Patchstack and Wordfence both sell one.

When the Site Doesn’t Need WordPress

Everything above is about managing an attack surface. For some sites the better answer is not having one.

A good share of the sites we look after are brochure sites — a handful of pages, a contact form, text that changes a few times a year. WordPress runs that perfectly well, but it brings a database, PHP and a set of plugins that all need watching, and every one of those is a row in the chart above.

We also run AI Sites, which builds that kind of site as static pages instead. AI Sites is a registered business name of WP Care Limited, so it is us either way. There is no WordPress install, no plugins and no plugin update cycle. Builds are €249 for a single-page site or €349 for multi-page, then €15 a month for hosting, SSL and editing access, all excluding VAT.

It is not the answer for everything. If you need a shop, bookings, memberships or anything with logged-in users, that is WordPress work and the maintenance goes with it. Where a site really is just a shopfront, the static build takes the plugin update cycle out of the picture rather than managing it.

For a once-over on where your site sits, get in touch or see our managed WordPress care plans.

Andrew

Andrew is a Wordpress enthusiast, web developer and founder of WP Care.