WordPress Security in 2026 What the Data Says and What You Must Do

Hat tip to Roger Monti for staying dog-on-bone about WordPress security front. We need more like that!

I am lucky enough to have several ongoing consulting positions with SEO firms. That has allowed me over the years to look behind the curtains of hundreds of websites running WordPress. The most troubling thing is how many sites are running plugins that haven’t been updated in weeks, months and in some cases – flippin years.For the life of me, I can not understand why WordPress.org has not put in place a ‘deprecation’ process where plugins that have not been updated after a exploit exposure are removed and/or disabled by default on sites.Obviously, WordPress remains the beast of a CMS on the web. Which brings us to: the volume of security vulnerabilities continues to rise quickly. Monthly reporting from SolidWP throughout 2025 has shown hundreds upon hundreds of plugin and theme vulnerabilities week after week. Many of those are unpatched months after they’re disclosed.

At the same time, monthly updates from agencies like Developress underscore how attackers focus on the top most popular extensions and take advantage of lame slow patching cycles by developers, site owners, agencies, and mom & pop sites.

<aside>Do you know how easy it is to download a plugin, dump it into ChatGPT, and say “review our script for vulnerabilities and how an hacker would attack them”? I just ran 8 of the plugins (your using right now) through that process and found:

10 “d-grade” concerns but not issues.
3 “c-grade” say, that might be a problem if conditions are right (often these require an account on the site)
1 “b-grade” issues that require a login and certain conditions to be true.
and one bonifide “A-grade” red alert type issue with a plugin (fortunately, our platform does not allow this type of xss exploit due to server config) (we alerted the developer)

Now imagine an exploit shop that is automating the above scenario through and LLM themselves with OpenClaw. After running “all” of the plugins in the entire wordpress directory through your exploit exposer, you would have the LLM to show you how to enact the exploit. Lastly, the shop could have automated agents that immediately go out and test the exploit on 10k sites in a few minutes. That is what we are up against – this is automated hacking on a massive scale.

Now, you devs that don’t have “automatic updates” turned on for every plugin. umm really? It is only matter of time before – not if – you are hacked. I mean I get that it used to be an issue where some plugins or WordPress themselves could brick a site with an incompatible update, but those days are gone. I’ve had auto update on, for several years now on a dozen sites with different plugins and themes – no issue.

The Reality: WordPress Vulnerabilities Are Increasing

In 2024 the WordPress ecosystem saw almost 8,000 new security vulnerabilities, roughly 22 per day. Nearly all of these were in third-party plugins, and a tiny fraction were in themes.

Of the 8000 vulnerabilities found last year, only seven vulnerabilities were found in WordPress core, and none were considered widespread threats. All were updated within 48hours of disclosure.

Key takeaways:

Plugins account for about 96 percent of new vulnerabilities.
More than 30 percent of new vulnerabilities were likely to be actively exploitable.
A large share of vulnerabilities were never fixed before public disclosure.
Many require no authentication before exploitation.

That should change how site owners, developers, and content teams treat vulnerability risk.
Below are what the stark numbers show and what you and your team (please get off your butt about WP security – before a major incident is going to happen) need to do about them.

30 percent of new vulnerabilities were likely to be actively exploitable

What the Data Shows

Vulnerability volumes remain extremely high

Mid-December 2025 weekly SolidWP reports showed 170 new vulnerabilities, including three with critical remote code execution risk, of which 91(!) remained unpatched at the time of disclosure. whoa!
Earlier SolidWP weekly reports found dozens-to-hundreds of new disclosures each and every week.
For example: 118 new vulnerabilities on Oct 29 and 139 disclosed on Dec 31, with between 26 and 73 unpatched in each period.
Recent weekly data from February 2026 shows 244 new disclosures, with 80 still unpatched.

These figures strongly confirm earlier observations from Patchstack’s 2025 mid-year report that plugin vulnerabilities dominate the ecosystem, and that unpatched holes are common.

Core vs plugin risk

Core WordPress is rarely the reason sites get hacked anymore. The largest slice of exploits and issues comes from 3rd party plugins and themes of course.
In contrast with plugin vulnerabilities showing up continually and many either fixed slowly or not at all.

Case example: plugin security confusion

A WordPress.org support thread around the Groups plugin illustrates a common issue: different scanners and vulnerability feeds sometimes report opposing and conflicting info about whether a version is actually secure or not. Obviously this signals that you cannot rely on a single tool’s report alone.

Actions for Developers

Security has to be part of development cycle planning and deployment, not something you address when it breaks. As a plugin developer myself, I have struggled to maintain code up-to-date at times. So as a site owner and webmaster, we follow the following actions.

1 Inventory All Installed Code

Before adding a plugin or theme to any WP environment:

List the active installed count, last updated date, and changelogs that you have.
Lookup known issues in at least two sources (CVE database, Patchstack, SolidWP, Wordfence).
Avoid adding components that haven’t been updated in months.

If a component has a history of long term repeated vulnerabilities, it would be wise to consider alternatives.

2 Treat Vulnerabilities Like Fatal Bugs

Respond to vulnerabilities with the same urgency you give fatal critical bugs:

Set severity rules: treat critical and high-impact findings as deployment blockers.
Use automated scanners in your continuous integration workflows.
Bind updates and patching tasks with deploy checklists so nothing slips through the cracks.

3 Use Defenses That Understand WordPress Structure

Standard application firewalls and generic host protections often miss attack vectors specific to WordPress plugins.

Use security layers that can apply virtual patches or real-time mitigations at the application layer.
In cases where a patch doesn’t exist yet, isolate or deactivate the risky plugin.

4 Measure What You Patch

Track how long it takes you to apply critical patches after disclosure. A measured target (for example, 24hrs for critical or high severity) gives you a way to improve over time.

What Marketers Should Do

We watched a firm go through getting their Google account hack – it devastated business for some time. One firm just told me they never recovered with clients after a mid-2025 hack. It can have real and lasting effects to be hacked. Security has real consequences for brand trust, uptime, and SEO.

1 Build Security Milestones Into Product Calendars

When planning content or product launches:

Set aside time for vulnerability scanning and patching.
Communicate with dev teams about upcoming pushes and dependencies on plugin versions.

This avoids emergencies during peak activities.

2 Reduce Feature Bloat

Every plugin you add multiplies potential attack vectors and feature bloat is a real concern. Last minute changes are always a bad idea:

Regularly audit marketing tools (popups, forms, SEO plugins).
Remove tools that aren’t delivering measurable value.
Consolidate functionality when possible.

Fewer moving parts means fewer things to break and fewer to secure. Seriously, do a scan of your plugins with an llm and look for issues.

3 Educate Content Owners on the Risks Involved

Create a simple internal guide your content teams can use (use and LLM to generate it and then READ it):

Do not install plugins yourself.
Report errors or warnings in the admin dashboard immediately.
Forward any vulnerability notices from scanning tools to development quickly.

This cab bridge the gap between operations and security.

4 Share External Transparency With Users

If breaches happen, communities appreciate honest security communication. You have to disclose it, or long term issues will ensue.

Publish regular security update summaries.
Explain the measures you take to protect user data.
When you patch a serious issue, call it out in internal operations updates.

While this won’t stop attackers, it builds confidence with partners and users.

Simple 24-Hour Triage Checklist

Use this minimum checklist any time a new report drops:

Update WordPress core to the latest secure release.
Check the plugin list for items with critical or high severity disclosures.
Validate patches are available. If not, deactivate the component.
Review user accounts for unnecessary privileges.
Snapshot a fresh backup before applying any bulk updates.

This turns raw vulnerability signals into repeatable action.

Final Word

Reports show hundreds of new vulnerabilities disclosed every week, and huge numbers remain unpatched when they are first published.

That means you cannot set and forget your security posture. Be proactive, deliberative, and systematic about how you choose plugins. Then be vigilant in how you patch them, how you test updates, and how you involve non-technical teams in your wordpress defense planning. The teams that treat security as part of routine work will have fewer breaches, less downtime, and fewer last-minute scramble fire drills.

Lastly, don’t be an idiot – turn on auto-update on your plugins!