WordPress Plugin Vulnerabilities in 2025: What to Actually Check Before You Install

WordPress ecosystem vulnerabilities hit an all-time high in 2025 — over 11,000 newly disclosed issues, the highest number ever recorded for a single year. That statistic alone is worth sitting with before you install another plugin without checking anything about it first, because the pattern behind that number is specific and mostly avoidable.

The actual scale of the problem

Patchstack’s “State of WordPress Security” report puts 2025’s total at 11,334 newly disclosed vulnerabilities across the WordPress ecosystem — up 42% from 7,966 in 2024, and the highest figure Patchstack has recorded. Of those, 91% were found in plugins, 9% in themes, and a mere 6 vulnerabilities in WordPress core itself across the entire year. That last figure is worth pausing on: core is, by a huge margin, the most scrutinized and best-maintained part of the average WordPress install. The risk overwhelmingly lives in the plugin layer, not in WordPress itself.

Patchstack’s mid-year 2025 report recorded 6,700 new vulnerabilities disclosed in just the first half of the year, with 41% of them confirmed exploitable in real attacks — not just theoretical weaknesses. The median time between a vulnerability’s public disclosure and its first real-world exploitation attempt was just 5 hours, and 46% of disclosed vulnerabilities had no patch available yet at the moment they were disclosed.

A five-hour median window between disclosure and first exploitation attempt means the old advice to “update when you get a chance” is no longer a safe cadence for security-relevant plugin updates. Attackers are watching disclosure feeds directly, not waiting for you to notice.

What the volume actually looks like, quarter by quarter

Wordfence’s Q4 2025 threat intelligence report recorded 2,213 new vulnerabilities disclosed in that quarter alone. Separately, Forbes reported Wordfence blocked 1.6 million individual attacks against WordPress sites within a single 48-hour window in late October 2025. Those two numbers together paint a consistent picture: both the discovery of new vulnerabilities and the volume of active exploitation attempts against WordPress sites are large and ongoing, not occasional spikes.

I want to flag something directly: these figures all come from security vendors — Patchstack and Wordfence — reporting on their own tracked data, not from an independent, neutral third party auditing the entire ecosystem. That doesn’t make the numbers wrong; both companies have strong incentives to track this accurately, since it’s core to their business. But it’s worth attributing these stats to their source rather than treating them as some kind of official WordPress.org-published figure, which they aren’t.

What to actually check before installing a plugin

Given that plugins account for the overwhelming majority of vulnerabilities, and that exploitation can begin within hours of disclosure, a genuine pre-installation check is worth the few minutes it takes:

• Check the last-updated date in the plugin repository listing. A plugin that hasn’t been updated in over a year, especially one handling forms, uploads, or user data, is a meaningfully higher-risk install than one with active, recent maintenance.
• Check the active install count and support forum activity. A large install base with an active support forum generally means more eyes finding and reporting issues — and more pressure on the developer to patch quickly when something’s found.
• Look up the plugin’s vulnerability history through Wordfence’s or Patchstack’s public vulnerability databases before installing, not just after something goes wrong. Both maintain searchable, publicly accessible records.
• Minimize plugin count generally. Given that 91% of disclosed vulnerabilities are plugin-based, every additional plugin is genuinely additional attack surface — not a neutral addition, even if it’s well-maintained.
• Set up automatic updates for plugins where you reasonably can, given how short the real-world window between disclosure and exploitation has become. Manual, occasional update checks are no longer a comfortably safe cadence on their own.

Why plugins carry so much more risk than core

The 91%-plugins-versus-6-vulnerabilities-in-core split isn’t really a coincidence of who happens to write better code. WordPress core has a small, tightly coordinated team, a mature security-review process, and a huge number of security researchers actively looking for issues precisely because finding one in core is high-profile. A plugin from a small independent developer, or one that hasn’t been actively maintained in years, has none of that structural scrutiny — which is exactly why the vulnerability count concentrates there so heavily. That asymmetry is a genuinely useful mental model: the deeper a piece of functionality lives outside WordPress core’s own review process, the more the responsibility for its security shifts onto whoever chose to install it.

What this means for an existing site, not just new installs

The same logic applies retroactively to plugins already running on your site, and this is the part people skip: audit what’s already installed, not just what you’re about to add. A plugin that was safe and well-maintained when you installed it three years ago may have since been abandoned, sold to a new owner with different priorities, or simply fallen behind on patching known issues. Given how much of the ecosystem’s vulnerability count concentrates in the plugin layer, and how quickly disclosed issues get exploited in practice, periodically re-auditing your existing plugin list — not just your next new install — is the habit that actually moves the needle on real-world risk.

A specific pattern worth watching for: ownership changes

One risk category that a simple “last updated” check won’t reveal on its own is a plugin quietly changing ownership. A once-reputable, actively maintained plugin can be sold to a new owner whose priorities — or security practices — differ significantly from the original developer’s, sometimes without any prominent announcement to existing users. This has been a real, documented pattern in the WordPress plugin ecosystem, occasionally surfacing as a plugin update that adds unexpected functionality unrelated to its original purpose. If a plugin you depend on suddenly changes its changelog tone, adds features that feel disconnected from its original scope, or gets updated by a name you don’t recognize from its history, that’s worth a closer look before simply approving the update automatically.