Why WordPress Vulnerabilities Rise and How to Stay Safe

WordPress vulnerabilities logged in our database went from 1,721 in 2021 to 11,072 in 2025. That's a six-fold increase in four years, and 2026 is already at 7,620 disclosures as of September 12, on pace to land somewhere near last year's total. Every published security report agrees the number keeps climbing. This post is about why, and about what a site owner should actually do with that.

We covered where the disclosure count comes from and how it splits between plugins, themes, and core in our vulnerability data breakdown. This post picks up from there. It looks at why the yearly total keeps rising, why that's only half a bad story, and what actually closes the gap between a disclosure and an attack on your own site.

The numbers

Here's the year-by-year shape of it, pulled from our own database as of September 12, 2026.

Year	Disclosures	Plugins	Themes	Core	Titled "Unauthenticated"	No fixed version listed
2021	1,721	1,615	96	10	5.2%	19.8%
2022	3,488	3,261	205	22	4.9%	21.4%
2023	5,931	5,702	215	14	5.7%	22.2%
2024	8,521	8,165	351	5	11.6%	22.7%
2025	11,072	10,085	985	2	18.8%	41.8%
2026 (to Sep 12)	7,620	6,712	891	17	35.4%	24.7%

Two columns are worth pausing on. "Titled Unauthenticated" only counts advisories whose title says outright that no login is needed, and it more than tripled between 2023 and 2025. Published industry reports usually count more broadly, including flaws that need a victim to click something, so their unauthenticated percentages read higher than ours. Same underlying trend, different yardstick.

Our totals track the outside reports closely enough to trust the shape of the trend: 11,072 disclosures in our 2025 count against 11,334 in Patchstack's State of WordPress Security 2026 report, which counts per affected product rather than per advisory. Patchstack put 2025's growth at 42% year over year, with high-severity flaws up 113% and 46% of everything unpatched at the moment it was disclosed. Wordfence's own count for 2024 was 8,223 CVEs, up 68% from 2023.

Look at what's actually breaking in the last 12 months of our data and the mix isn't exotic. Cross-site scripting leads at 31.1%, missing authorization is second at 23.2%, then SQL injection at 7.1%, CSRF at 5.9%, information exposure at 4.3%, object injection at 3.1%, privilege escalation at 2.9%, file upload flaws at 2.2%, and everything else at 20.1%. These are old, well-understood bug classes. Nothing here needed a novel attack technique to find.

Why the WordPress vulnerabilities count keeps rising

Most of the growth through 2025 has a boring explanation: more people got paid to look.

Wordfence's own 2024 annual report says it plainly: "a large portion of the increase from 2023 to 2024 is a direct result of the launch of the Wordfence Bug Bounty Program," which alone published 3,427 of that year's disclosures, 42% of the total. Patchstack's researcher community nearly doubled to 179 active researchers over the same stretch. Jerry Gamblin's review of 2025's global CVE data found Patchstack was the single largest CVE issuer on the planet that year, 7,007 CVEs, with Wordfence at fifth place with 3,451. Between the two of them, that's over 10,400 of the 48,185 CVEs published anywhere in 2025.

That's an incentive structure doing exactly what it was built to do. Pay researchers per bug, and researchers find more bugs.

2026 adds a second force to that: AI-assisted research. WordPress.org's Core Security Initiative post from August 28, 2026 acknowledges "a substantial increase in the volume of incoming security reports" and credits frontier AI models for it. Its disclosure program narrowed what it accepts on September 1, dropping contributor-level reports for non-core assets. Patchstack made the same call earlier, pulling contributor-role reports out of its bug bounty scope from June 1, 2026, citing "a significant increase in lower-impact reports" once AI-assisted research took off. Separately, researchers at TrendAI used AI tooling to surface more than 300 critical plugin zero-days in 72 hours, every one of them manually verified.

Neither WordPress.org nor Patchstack has published a number for how much of the increase AI accounts for, and we're not going to invent one. What's documented is that both organizations felt it land hard enough to change their intake policies within months of each other.

Why the underlying code problem is real anyway

None of that means the code got better while the count went up for unrelated reasons. Some of it is a real quality problem, and the data backs that up too.

Most of the plugin ecosystem is small teams. Wordfence found 58% of 2024's flaws sat in plugins with under 10,000 installs, and 37% in plugins under 1,000. That's the long tail, often built and maintained by one or two people without a security review process behind them.

Premium software isn't a free pass either. Patchstack's 2026 report found premium and freemium plugins made up 29% of 2025's disclosures but carried three times the known-exploited flaws of free plugins.

A lot of what gets reported is developers reaching for the wrong tool. We've written before about how a nonce answers "did this request come from my own page," not "is this caller allowed to do this" (here's the full explanation), and that exact confusion turned a Super Forms upload handler into a critical, unauthenticated file upload CVE. Missing authorization sits at 23.2% of last year's disclosures for a reason, and Patchstack named broken access control as 2025's most exploited class overall.

And until this year, nothing stood between a developer publishing a plugin release and every site on that plugin auto-updating into it. WordPress.org added a 6-hour cooldown on new plugin releases starting June 5, 2026, and on September 9 layered in AI plus Jetpack Scan review during that window, auto-blocking releases it flags as high-risk. Before 2026, a bad release just shipped. Separately, Patchstack's 2025 report noted 1,614 plugins and themes were pulled from wordpress.org over the course of 2024 because their security issues went unpatched.

Where sites actually get hurt: the patch gap

Disclosure counts explain the headlines. What actually gets a site compromised is the gap between a fix existing and that fix landing on your install.

Patchstack's number for 2025 is 46% of vulnerabilities unpatched at the moment they were disclosed, up from 33% the year before. Wordfence found roughly 35% of 2024's flaws were still unpatched by April 2025, months later, and traced a chunk of that to developers who were simply unreachable or unresponsive. In our own database, the share of 2025 disclosures with no fixed version listed at all sits at 41.8%, higher than any prior year.

The window that matters most is how fast that gap gets exploited once it opens. Patchstack put the median time from disclosure to exploitation at about 5 hours in 2025. Two real cases from our own coverage show what that looks like in practice. Elementor Pro's CVE-2026-32475 was under active attack the same day the fix shipped. The miniOrange SAML SSO plugin's paid editions were patched with no public advisory at all, which meant a vulnerability scanner checking only public disclosure data would have shown those sites as clean while they were actually still exposed.

Firewalls at the hosting layer don't close this gap on their own. Patchstack measured them blocking 26% of generic exploit attempts and only 12% of WordPress-specific ones, the category that matters here.

Core is a tiny fraction of the disclosure count, but it isn't exempt from being actively exploited once something does surface. CISA added two WordPress core flaws to its Known Exploited Vulnerabilities catalog on July 21, 2026: CVE-2026-60137, a SQL injection, and CVE-2026-63030.

None of this is abstract for the sites it hits. Sucuri's SiteCheck found 1,176,701 infected sites across 70.8 million scans run in 2024, about 1.66% of everything it looked at. And the regulatory pressure is starting to point the same direction as the data: the EU's Cyber Resilience Act requires vendors of commercial software to send an early warning within 24 hours when one of their vulnerabilities is actively exploited, a rule that took effect September 11, 2026. Speed is becoming the expectation, not just the ideal.

How to keep your site safe

Every step below answers one of the causes above. None of it is generic advice; each one closes a specific gap the data shows is actually open.

Cause in the data	What closes it
46% unpatched at disclosure, ~5 hour median to exploitation	Auto-update, patch security releases the same day
1,614 plugins and themes pulled in 2024, 58% of flaws in sub-10k-install plugins	Remove unused plugins, replace abandoned ones
Missing authorization 23.2%, broken access control the top exploited class	Least privilege, no open registration, prune old accounts
Hosting firewalls blocked only 12-26% of exploit attempts	A WAF layer that ships new rules fast, not just at the host level
Compromises happen even with tools installed	Scan from outside and inside, keep tested offsite backups

1. Close the patch gap

Turn on auto-updates for plugins and themes; WordPress supports this per-plugin from the dashboard. Update within hours of a security release, not within your usual weekly window. Keep premium plugin licenses active, since an expired license is a quiet way updates stop arriving without anyone noticing.

2. Remove what you don't use and replace abandoned plugins

Check a plugin's last-updated date, whether it's ever been closed on wordpress.org, and its disclosure history before deciding to keep it. You can look up any plugin's own vulnerability history for free on our vulnerability database, including a page for each plugin slug. A plugin nobody's touched in two years is a bet that nothing will be found, and the data says that bet loses often.

3. Choose plugins carefully before you install them

Before adding something new, check the same three things: an actively maintained changelog, a developer who responds to support threads, and a clean or quickly-patched security history. A large install base isn't a guarantee, but it usually means more eyes have already looked.

4. Enforce least privilege

Turn off open user registration if your site doesn't need it. Give contributor-and-above roles to as few accounts as possible, and remove ones nobody uses anymore. Missing authorization and broken access control aren't rare edge cases in the data; they're the second-largest and most-exploited classes going.

5. Protect logins directly

Two-factor authentication on every admin account, unique passwords per person, and as few admin accounts as the site can actually run on. None of this stops a plugin vulnerability, but it takes stolen and guessed passwords off the table as a way in.

6. Add a layer that reacts faster than your update schedule

A web application firewall that ships rules for newly disclosed plugin flaws covers the hours between disclosure and your own patch, which matters given hosting firewalls alone caught only 12% of WordPress-specific exploit attempts in Patchstack's data.

7. Detect problems from both outside and inside

External scans catch what's visible on the surface: outdated plugin versions, exposed files, blacklist status. Server-side checks catch what isn't: injected database rows, modified core files, PHP dropped where it shouldn't be. Run wp core verify-checksums periodically, and disable PHP execution inside wp-content/uploads so an upload flaw can't turn straight into code execution.

8. Keep offsite backups and actually test a restore

A backup nobody has restored from is a guess, not a plan. Store backups somewhere other than the server they're backing up, and prove the restore works before you need it.

9. Monitor continuously, not once

A plugin clean today can carry a critical flaw next month. A one-time check tells you about today.

For the full baseline hardening pass beyond what's above, our WordPress security checklist covers the rest step by step. If you're past prevention and think something's already wrong, start with the signs your site's been hacked and our malware removal guide.

WP Vanguard's free surface scan checks the plugin versions it can detect against our vulnerability database, plus security headers, blacklist status, and exposed files. The deep scan goes server-side: PHP files sitting in uploads, malware signatures, database injections, and modified core files. Registered sites also get scheduled scans, alerts when a newly disclosed vulnerability affects a plugin you have installed, uptime and SSL and domain expiry monitoring, Google Safe Browsing blacklist checks, and a weekly security digest.

What not to rely on

A security plugin by itself isn't enough. Malware that gets in can disable the very tools meant to catch it.

Your host's firewall alone won't cover you either, not at a 12% catch rate on WordPress-specific attacks.

"We update monthly" doesn't hold up against a median exploitation time of 5 hours.

And a clean scan doesn't mean a clean plugin if you're running a paid edition a public vulnerability database has never heard of. That's exactly what happened with miniOrange's SAML plugin: patched quietly, so nothing showed up as a known issue.

For developers

Check permissions with current_user_can(), not a nonce. A nonce proves a request came from your own page recently; it says nothing about whether the caller is allowed to do what they're asking. Every REST route needs a real permission_callback; leaving it out, or returning true from it, makes the route public. And escape everything on output, every time, regardless of what validated it on the way in.

Run a free WP Vanguard scan to see where your own site stands against the plugins and flaws behind these numbers.