Is WordPress Secure? What 67,678 Vulnerability Disclosures Show

Our database has logged 67,678 WordPress vulnerability disclosures since June 9, 2003, twenty-three years of advisories pulled mostly from Wordfence's threat intelligence feed. That number is a big part of why "is WordPress secure" pulls up so many alarming headlines. But split it by where each flaw actually lived and the story changes. WordPress core accounts for 391 of those 67,678 disclosures. That's 0.58%. The remaining 99.4% belongs to plugins and themes: third-party code that anyone with a WordPress.org developer account can publish.

That split matters because "WordPress is insecure" almost never turns out to mean the CMS itself. It means an extension ecosystem of tens of thousands of independently maintained plugins, most run by one or two people, some effectively abandoned. Understanding what the big number actually measures, and where it comes from, tells you more about running a WordPress site safely than the number itself does.

How the 67,678 disclosures break down

Plugins carry the overwhelming majority, 93.2% of everything in the database, spread across 16,067 distinct plugin slugs. Themes add another 6.3% across 2,156 slugs. Core, meaning WordPress itself, sits at 0.58% across exactly two tracked products.

Worth sitting with for a second: 16,067 distinct plugin slugs is roughly a quarter to a third of the 60,000 to 70,000 free plugins WordPress.org currently lists, meaning most plugins in the directory have never had a single public disclosure in their entire history. That's not proof they're clean, plenty of vulnerable code simply hasn't been looked at yet, but it does mean the 63,054 plugin disclosures are concentrated, not evenly spread across the whole catalog.

2026 year to date follows the same shape, if anything more skewed. Plugins: 7,144 disclosures across 3,410 slugs. Themes: 1,009 across 769 slugs. Core: 17 disclosures, about 0.2% of this year's total. July 2026 alone produced 1,108 disclosures, 60 of them rated critical. August 2026 produced fewer overall, 929, but 75 were critical, a smaller month with a worse severity mix.

One honest caveat here: this database aggregates public advisories, overwhelmingly from Wordfence. It measures disclosures, not incidents, and definitely not confirmed exploitation in the wild. A plugin can collect five disclosures over its life and never once get exploited on a real site, while a quieter plugin with a single CVE gets hit constantly. For the raw monthly numbers behind this pattern, see our August 2026 vulnerability roundup.

Why comparing WordPress to npm is harder than the headlines suggest

The obvious rebuttal to "plugins are 99% of the problem" is scale: WordPress ships an enormous amount of third-party code, so naturally it racks up disclosures. Fair, but the comparison cuts both ways once you look at the actual numbers.

npm's public registry held roughly 4.04 million packages as of May 2026, based on the registry's own replication endpoint. The WordPress.org plugin directory holds somewhere between 60,000 and 70,000 free plugins, depending on which count you trust and when it was taken. npm is on the order of 60 times larger by package count. If disclosure volume simply tracked ecosystem size, npm's vulnerability count should dwarf WordPress's. It doesn't come close.

Part of the reason is that WordPress has a security research economy most ecosystems don't. Wordfence and Patchstack run paid bug bounty programs specifically for WordPress plugins, employ researchers who audit plugin code full-time, and file CVEs as a matter of routine practice. Nobody runs an equivalent operation combing through 4 million npm packages line by line. A high disclosure count is partly a measure of how hard people are looking, and in WordPress's case, people are looking hard.

The sharpest evidence for that comes from a different kind of attack entirely. Phoenix Security tracked 59 supply-chain campaigns between June 2024 and June 2026, covering 657 malicious package indicators across npm, PyPI, VS Code and OpenVSX extensions, Golang, RubyGems, Cargo, and NuGet. npm accounted for 79.3% of the malicious packages, PyPI another 9.0%. Across all 59 campaigns, the number of CVEs assigned during active exploitation was zero.

That's not a rounding error. It means malicious-package attacks in those ecosystems routinely never become a countable CVE at all. The TrapDoor campaign is a good example: 34 packages and more than 384 versions hit npm, PyPI, and Crates.io simultaneously, detected by Socket in under six minutes, and it doesn't appear in the CVE database because nobody files a CVE for a package an attacker published to be malicious from day one. CVEs are built for flaws in legitimate software, not for malware wearing a package name.

Between early June and mid-July 2026 alone, npm and PyPI absorbed four more attacks in that mold: a Shai-Hulud worm variant spreading through PyPI, typosquatted packages impersonating PaySafe and Skrill payment SDKs, a stolen npm publishing token used to push malicious versions of a real package, and a hijacked CI pipeline that briefly served malware through a package pulling 2.25 million weekly downloads. Every one of those is a real, damaging attack. None of them shows up when someone counts CVEs per ecosystem and compares the total to WordPress's.

None of this proves WordPress is the safer platform. It proves the two disclosure counts aren't measuring the same thing. WordPress's number counts flaws researchers found and reported through an established pipeline. A meaningful share of npm's actual attack surface never enters that pipeline at all, because the attacks are deliberate malware rather than accidental bugs, and deliberate malware doesn't get a CVE.

The one place WordPress genuinely is behind

Here's where the platform doesn't get a pass. WordPress.org has no review process for what happens when a plugin changes ownership. Anyone can sell a plugin, hand over the SVN credentials, and the new owner can push an update the next day with no scrutiny beyond WordPress.org's normal, fairly thin plugin review. npm and PyPI both tightened their own publishing controls and account security requirements years ago, after their own ownership and credential incidents. WordPress hasn't closed the equivalent gap.

The Essential Plugins case shows exactly what that gap costs. An attacker bought a portfolio of more than 30 WordPress plugins, with roughly 400,000 combined installations, through Flippa for a six-figure sum. The first malicious commit landed in version 2.6.7 on August 8, 2025, disguised as a routine WordPress compatibility check but carrying a PHP deserialization flaw wired to an attacker-controlled server. It sat dormant for roughly eight months.

On April 5 and 6, 2026, it activated across the installed base, pulling down a payload that served spam and cloaked pages to Googlebot while staying invisible to site owners. WordPress.org closed all 31 plugins within a day and pushed a forced update, but that update didn't remove the code the backdoor had already injected into wp-config.php. Sites needed manual cleanup on top of it. We covered the full mechanism in our Essential Plugins backdoor writeup.

WordPress isn't exempt from the infrastructure-compromise style of attack that dominates npm either. In July 2026, WPManageNinja migrated its store off Easy Digital Downloads and left an old server running, with proxy rules still routing a few endpoints to it. An attacker found that forgotten server and used it to serve backdoored builds of Fluent Forms Pro 6.2.7 and Ninja Tables Pro 5.2.11 for about five hours on July 31, between 14:00 and 19:00 UTC.

The company caught it, shut the server down, and shipped clean 6.2.10 and 5.2.14 releases. Roughly 295 customer accounts actually pulled a compromised build, out of 1,368 notified as a precaution. That's the same attack shape as a hijacked npm CI pipeline: not a code vulnerability, a compromised distribution channel. We walked through the incident and the cleanup in our writeup on the Fluent Forms and Ninja Tables backdoor.

Neither of these is a CVE-count problem. Both are ownership and infrastructure problems, and WordPress.org's plugin review process wasn't built to catch either one.

What to do differently

None of this means run fewer plugins or trust WordPress less. It means the risk sits in specific, checkable places rather than in the platform itself.

Watch for a plugin that goes quiet for a year or two and then gets a burst of updates from an author name you don't recognize. That exact pattern preceded the Essential Plugins backdoor: a portfolio of formerly active plugins, sold quietly, then updated by a new owner with no public announcement most site owners would have seen. Check the WordPress.org plugin page's "Changelog" and "Contributors" tabs before trusting an update from a plugin you haven't touched in a while. If the listed author changed and there's no support-forum thread explaining why, that's worth a pause before you update.

Read changelog entries that claim to be routine, "compatibility fix" or "minor update," but ship an unusually large diff. That's exactly how the malicious Essential Plugins commit was framed, and it's checkable: WordPress.org's SVN repository shows the diff for every release, not just the changelog text a developer chose to write. A one-line description covering hundreds of changed lines is a reasonable trigger to actually look.

Treat nulled copies of premium plugins as a worse version of the same ownership problem, not a separate one. You're trusting an anonymous distributor to not have modified the code, with none of the scrutiny even a legitimate ownership transfer gets from WordPress.org. We go into that specific risk in our piece on nulled WordPress plugins.

And when a vendor announces an infrastructure migration, like WPManageNinja's move off Easy Digital Downloads, treat the following weeks as a period worth extra attention rather than a one-time headline. Decommissioned servers, stale proxy rules, and forgotten credentials are exactly what got exploited there, and that class of mistake tends to surface days or weeks after the migration is announced, not during it.

For general hardening and how sites get compromised in the first place, our WordPress security checklist and how WordPress sites actually get hacked already cover that ground, so we won't repeat it here. WP Vanguard's scans flag plugins with recent ownership changes or unusual update patterns for exactly this reason: that's where the real risk inside the 67,678-disclosure number concentrates, not in the raw count itself.

References

• Phoenix Security: Accelerating Supply Chain Attacks in npm, PyPI, VS Code, and AI-Enabled Ecosystems
• GitGuardian: Shai-Hulud and the npm/PyPI Supply Chain Attack Wave
• InfoQ: WordPress Plugin Portfolio Supply Chain Attack
• The Hacker News: TrapDoor Supply Chain Attack Spreads Across npm, PyPI, and Crates.io
• WPManageNinja: Security Incident on 31 July 2026