The short answer
Core is not where the risk lives.
Patchstack tracks WordPress vulnerabilities two ways, and the two numbers don’t match:
- Patchstack’s live database: 20 core vulnerabilities out of 11,259 tracked in 2025. That is 0% of the total.
- Patchstack’s 2026 whitepaper: 6 core vulnerabilities out of 11,334 tracked in 2025. The whitepaper calls these “low priority” issues.
This guide won’t average the two or pick a winner. Either way, the core sits at roughly 0 to 0.2% of everything tracked in 2025. Both reports agree on the rest: plugins account for 91% and themes for the remaining 9%.
The other half of “is WordPress secure” is a market-share question, not a security one.
As of 21 August 2026, WordPress runs 40.7% of all websites. It runs 58.9% of every site with an identifiable content-management system. That is according to W3Techs, an independent source that tracks this directly. WordPress’s own security page gives a different figure: “more than 43% of the web”. That is WordPress’s self-reported number. Don’t average the two.
Running the largest share of the web makes WordPress the largest target pool. That is arithmetic, not the same as being the least secure platform on the web. The distinction matters before you look at what hardening actually covers.
How WordPress security actually works
Core, plugins, and themes get patched in different ways. That difference explains most of what follows.
How core gets patched
WordPress 3.7 introduced automatic background updates for core. The goal was security.
Before WordPress 5.6 (released December 2020), a new install auto-updated only minor releases and translation files by default. From 5.6 onwards, a new install auto-updates both minor and major releases by default. WordPress’s own documentation calls turning that off “strongly discouraged”.
Who patches the core? In WordPress’s own words: “more than 50 trusted experts, including lead developers, security researchers, and key contributors to every component of WordPress.” They even backport fixes to older, unsupported versions as a courtesy. No one is obligated to keep running those fixes for you, but the team ships them anyway.
Open the site’s update settings, or ask whoever manages hosting. Check that both minor and major core updates run automatically, not just minor ones.
Why plugins and themes are different
Plugins and themes don’t get the same treatment as core.
WordPress.org’s security team can force an update to a specific plugin or theme, but only “in special cases”. This happens through the WordPress.org API, when a critical vulnerability needs patching everywhere at once, no matter what the owner set up.
Outside that rare case, keeping a plugin or theme current is the owner’s job. An abandoned plugin stops getting fixes but stays installed, active, and reachable, which is the exact gap the 2025 numbers describe above.
What a firewall or security plugin actually catches
A firewall or security plugin checks the perimeter. It doesn’t patch anything.
Patchstack’s 2026 whitepaper cites two penetration-testing studies. Hosting-level defences blocked only 12% of attacks on known, already-disclosed vulnerabilities. That rate rose to 26% across a broader set of vulnerability types.
A real layer, working by matching known attack patterns at the edge. It doesn’t rewrite the vulnerable code inside a plugin.
It also can’t catch a backdoor already planted inside a theme or plugin file. That is exactly how a pirated (“nulled”) plugin works. The backdoor ships inside the same zip file a legitimate copy would use. Nothing forced its way in, so there is no signature to catch at the door.
What a compromise actually costs to recover from
What decides how a compromise ends? Not the firewall. The backup.
A tested, offsite backup lets you restore the site to a known-good point. Without one, you rebuild from nothing.
Whatever caused the breach, a vulnerable plugin, a guessed password, or a nulled theme, matters less at that point. What matters is whether you have a short restore ahead of you or a full rebuild.
Why it matters even if the core is well maintained
Sites still get compromised for a simple reason: almost all the attack surface sits in plugins and in what an owner does with them, not in core.
Core didn’t get worse. The exposure lives in the 91% of 2025’s tracked vulnerabilities that sat in plugins, plus outdated versions, abandoned installs, nulled downloads, and reused admin passwords. None of that runs through WordPress’s security team. An unpatched plugin isn’t an abstract risk score. It is a defaced homepage or a compromised checkout page, the kind of thing a customer notices before the owner does.
The 90% figure still gets repeated as if it were current. It isn’t. It traces back to Sucuri data from 2018, reported in a March 2019 Infosecurity Magazine article, which makes it roughly seven years stale. Whatever it measured about 2018 installs, it says nothing about security today, or even then. Treating it as a live statistic repeats the exact error this guide opened with: mistaking market share for a security score.
There is a quieter point worth stating. Leaving WordPress’s free, built-in core auto-updates on solves the smallest slice of the real risk, and it costs nothing. A site owner who does only that has correctly handled the roughly 0 to 0.2% that lives in the core, for free. It doesn’t touch the 91% sitting one layer up in plugins, which is a maintenance question, not something core patches for you.
What good WordPress security looks like
What actually reduces this risk is a short, concrete list, not a product:
- Keep core, plugins, and themes current. Test every update before it goes live, not after.
- Remove abandoned or nulled plugins and themes. Check for ones you forgot were still active.
- Use strong, unique admin credentials. Brute-force attacks against wp-login.php are their own attack surface, separate from any software bug. A weak or reused password doesn’t need a vulnerability to succeed.
- Run file-integrity or malware monitoring. It tells you when a file changed after installation, so it catches a compromise that already happened. It doesn’t stop the first entry; that is what the points above are for.
What to do about it
Start with the plugin list, not the firewall. Three actions cover most of this:
- 01Audit every installed plugin and theme. Remove anything unused or no longer maintained by its developer. An abandoned plugin doesn’t announce itself. It just stops getting fixed. NoDrama’s free WordPress audit tool does this scan in minutes if you would rather not do it by hand.
- 02Turn on core auto-updates for both minor and major releases, if they are not on already. This slice of the problem is free and already solved.
- 03Decide who runs tested updates, file-integrity monitoring, and backups: your team, or a retainer that does WordPress operations full-time. Either answer works. What matters is that someone actually does it. See plan pricing and what’s included to compare that against doing it yourself.
After any of the above, log the date and what changed. Use a spreadsheet or maintenance log, something that outlives whoever made the change and stays checkable later.
Common misconceptions
“A security plugin is a complete answer.”
It is a perimeter check, and it needs its own updates, like anything else on the site. The pentest figures above put its real block rate at 12 to 26% against known vulnerabilities. That is a partial layer, not a substitute for patching the plugin underneath.
“My host’s security features cover this.”
Hosting-level defences carry the same 12 to 26% block rate described above. They are the same category of perimeter defence. They harden the server. They don’t patch the vulnerable code inside a specific plugin.
“WordPress gets hacked constantly because it’s insecure.”
This usually traces back to the 90% figure: 2018 data, reported in 2019. It describes market-share exposure, not a security verdict. Running the largest share of the web means showing up in the largest share of hacked-site counts. That is just arithmetic, whatever the underlying security looks like.
What this does not solve
None of the above patches a specific vulnerable plugin for you. It doesn’t replace the judgement call of deciding a plugin is abandoned and removing it. It doesn’t replace reading what an update changes before it goes live, especially on a site that depends on that plugin working a certain way.
Automation and monitoring narrow where your attention needs to go. They don’t remove the need for it.
Is WordPress actually secure?
The software WordPress ships from wordpress.org, backed by a security team of more than 50 people and a habit of backporting fixes to old versions, is well maintained. It is not the meaningful risk.
What determines whether a WordPress site is secure is what runs on top of core and who keeps it current: which plugins are installed, whether they are still maintained, whether the admin password would survive a guess, and whether anything watches for a change after the fact.
That is a maintenance question about one specific site, not a verdict on the platform every site like it happens to run on.