Contents
- 01Understand where the risk actually sits. The short answer, and how it actually works.
- 02See why it matters for your site. Why it matters for your situation, and what good security discipline looks like.
- 03Know what to do and what still isn’t covered. What to do about it, and the common misconceptions.
The short answer on WordPress security risks
Of 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, 91 percent were found in plugins, 9 percent in themes, and only 6 low-priority issues were in core, per Patchstack’s 2026 State of WordPress Security whitepaper. That split is not close. Core’s share is statistically negligible against plugins alone.
The direct implication follows from the numbers, not from opinion: WordPress the platform is not where the risk sits. The unaudited third-party code running on top of it, chosen and installed by whoever manages the site, is.
How WordPress security risk actually works
Why plugins and themes carry the risk core does not
Core ships from a single, reviewed codebase. It’s maintained by a security team of more than 50 people who backport fixes to older versions rather than forcing every site onto the newest release to stay patched, per the WordPress Security Team’s own review process.
A plugin or theme is a different situation entirely. It’s an independently authored package, written by a separate developer of whatever skill level they happen to have. WordPress.org’s directory review checks a plugin at submission, but it doesn’t continuously re-audit every version update that ships after that. A plugin that passed review in 2022 can ship a vulnerable update in 2026 with no equivalent second check.
This is also where the cost math changes. Verified, tested updates catch the failure mode where a legitimate patch breaks something on the live site, which is a different problem from a plugin’s own code carrying a vulnerability in the first place. See what tested, verified updates actually cost to have covered for how that piece works.
For any plugin you’re evaluating, check whether it names a security team or a documented disclosure process on its own listing page. A plugin with neither has no equivalent of core’s review process behind it.
The four vulnerability classes behind nearly all plugin and theme issues
Nearly all of the 91 percent plugin figure and the 9 percent theme figure comes down to four recurring mechanisms, as WordPress’s own definitions of these vulnerability classes lay out.
SQL injection
Unsanitized input gets run as a database command instead of passed through a prepared statement.
Cross-site scripting (XSS)
Unescaped output lets attacker-supplied JavaScript run in a visitor’s or an admin’s browser.
Cross-site request forgery (CSRF)
A state-changing action fires using a logged-in admin’s own session, because the plugin skipped its nonce check.
Broken access control
A user reaches an action or a piece of data that should have required a higher capability level.
A nonce, in WordPress’s own terminology, is a Number Used Once. It’s the mechanism a plugin is supposed to check before it lets a state-changing action run, and a missing nonce check is what turns a normal admin action into a CSRF opening.
For a specific plugin, check its own changelog for language like “sanitization,” “escaping,” or “capability check” fixes. That’s usually the tell that one of these four classes got patched in that release.
Why this matters for a site you are responsible for
An outdated plugin isn’t a slow decay. It’s a published map. Once a vulnerability is disclosed along with its fix, any site still running the unpatched version becomes identifiable by version fingerprinting and targetable at scale by automated tools, per WordPress’s own hardening guidance, which states plainly that the exploit information for a disclosed vulnerability is almost certainly in the public domain once the fix ships.
An inactive plugin doesn’t remove that exposure. Its files still execute if they’re present on the server and registered, deactivation just stops the plugin from loading on the front end, it doesn’t delete the code. If you’re not using a plugin, delete it rather than deactivating it and leaving it there.
The same logic that connects an unmaintained site to slow performance connects it to exploitability: both come from code nobody is watching. See why an unmaintained site slows down the same way it gets exploited for how that overlaps.
What good security discipline actually looks like
Running fewer, well-maintained plugins from established developers who patch quickly is a real, measurable reduction in risk. Risk scales with how many separate third-party codebases a site is running, not with running WordPress itself.
Severity is the other variable worth watching directly. A high-severity vulnerability, 17 percent of 2025’s total per Patchstack, is associated with likely mass-scale, automated exploitation. That’s the practical test for how urgently a given patch matters: a plugin that’s unmaintained, has a large install base, and handles user input or authentication is high-risk regardless of how small it feels in your own stack.
See what a maintenance plan should actually include for how that discipline gets specified rather than assumed.
What to do about it
- 01Delete plugins you’re not using. Deactivating leaves the files on the server, where they still execute if registered.
- 02Check whether a plugin’s developer is still actively patching it. An abandoned plugin stays exploitable no matter how quickly you’d apply an update if one existed.
- 03Apply security updates on a defined schedule. Not whenever someone happens to remember.
- 04Confirm updates are tested in staging before they go live. A legitimate security patch can still break site functionality when applied blind, which is a different failure than the vulnerability it patches, and both need a fix.
Not sure how many plugins on your site are still actively maintained?
Send NoDrama your URL and get a free website audit, no pitch attached.
After any update, confirm the site still renders and the admin dashboard still loads before considering the patch applied. A rollback path only helps if someone checks that it worked.
Common misconceptions about WordPress security
“WordPress itself is insecure.”
Core’s share of 2025’s disclosed vulnerabilities was 6 low-priority issues, statistically negligible against plugins’ 91 percent. The platform isn’t the risk. The unaudited third-party code running on top of it is.
“A security plugin covers this.”
A security plugin helps with detection and hardening, but it doesn’t patch a vulnerable plugin’s own code. That code stays vulnerable until its own developer ships a fix, or a virtual-patching rule addresses it in the meantime.
“Popular plugins are safer.”
Popularity increases how worthwhile a plugin is to build an automated attack against. It doesn’t guarantee the code was reviewed for the four vulnerability classes above.
Getting this in writing matters as much as getting it right in practice. See what a maintenance plan should actually specify about updates for the language that closes that gap.
What this does not solve
Tested updates and staged rollback catch the case where a legitimate patch breaks something. They don’t find an undisclosed, zero-day vulnerability, and they’re not a substitute for a web application firewall or real-time malware scanning.
This guide isn’t a claim that any specific site is, or isn’t, currently compromised.
So, what are the real security risks of running WordPress?
The risk sits in the plugins and themes running on top of core, not in core itself, and it concentrates further in whatever is outdated, abandoned, or simply numerous. Fewer, actively maintained third-party codebases is the practical lever, not switching platforms.