18,321 Vulnerabilities. Not Where You Think.
WordPress carries 18,321 CVEs in the National Vulnerability Database. This number is frequently cited as evidence that WordPress is insecure. It is — but not for the reason most people assume. WordPress core — the base software maintained by Automattic — accounts for roughly 150 of those CVEs. The remaining 18,000+ originate in the plugin and theme ecosystem: third-party code written by independent developers, installed by site owners, and maintained at varying levels of diligence.
This distinction matters because it changes the nature of the problem. WordPress core is maintained by a professional security team with responsible disclosure practices and a regular patching cadence. The plugin ecosystem is a marketplace of 60,000+ extensions with no consistent security review, no mandatory vulnerability disclosure, and no guarantee of continued maintenance. The vulnerability count is not a WordPress core problem. It is an architectural problem: WordPress chose to be extensible through plugins, and the security consequences of that choice now dominate its risk profile.
The Patching Treadmill
A typical WordPress site runs 15-30 plugins. Each plugin is an independent software project with its own release cycle, its own developer, and its own vulnerability timeline. A security-conscious site operator must monitor vulnerability disclosures for every installed plugin, evaluate each patch for compatibility, test updates against the site's specific configuration, and deploy them before exploit code circulates. For 15-30 plugins, this is not a weekly task — it is a continuous process.
The operational cost of this patching treadmill is difficult to estimate precisely because organizations rarely track it as a discrete line item. But the labor is real: developer time reviewing changelogs, staging environment maintenance for testing updates, rollback procedures for broken updates, and incident response when a plugin vulnerability is exploited before a patch is available. For a site running 25 plugins with an average of 4 updates per plugin per year, that is 100 update cycles annually — each requiring evaluation, testing, and deployment.
The Abandoned Plugin Problem
Not all plugins are actively maintained. WordPress.org's plugin directory includes thousands of extensions that have not received an update in over two years. These plugins continue to function — WordPress does not disable outdated extensions — but they no longer receive security patches. A site running three abandoned plugins is running three pieces of software with known vulnerability surfaces and zero prospect of a fix.
The abandonment pattern is structural, not incidental. Most WordPress plugins are developed by solo developers or small teams as side projects. When the developer's priorities shift, the plugin enters indefinite maintenance limbo. The site owner who installed it three years ago may not know the plugin is abandoned. The vulnerability scanner that flags it may not distinguish between 'outdated' and 'abandoned.' The distinction matters: an outdated plugin will eventually be patched. An abandoned plugin will not.
Performance as a Hidden Cost
Security is not the only cost of the plugin model. Each plugin adds PHP execution time, database queries, and frontend assets to every page load. A WordPress site with 25 plugins loads 25 sets of CSS files, JavaScript libraries, and initialization routines — regardless of whether the current page uses any of them. WordPress's 36% Core Web Vitals pass rate is not a hosting problem or a theme problem. It is a plugin accumulation problem.
Compare this to Astro, which ships zero JavaScript by default and scores 90 in WebPulse. Or Hugo, which generates static HTML with no server-side processing and scores 100. These frameworks do not have plugin ecosystems because they do not need them — functionality is added through build-time integrations and composable libraries that only ship code that the page actually uses. The performance gap between WordPress at 36% Core Web Vitals pass rate and modern static frameworks at 90%+ is the cumulative cost of 25 plugins loading on every request.
The Real Cost of 'Free'
WordPress plugins are free to install. They are not free to operate. The cost arrives in patching labor, security monitoring, performance degradation, and breach risk. An organization running a WordPress site with 25 plugins is not running one piece of software. It is running 26 independently maintained software projects on a shared vulnerability surface, with no unified security team, no coordinated release cycle, and no guarantee that any individual component will be maintained next year.
The 18,321 CVE count is not a failure of WordPress core. It is the actuarial result of an architectural decision made in 2004: that extensibility through third-party code would be WordPress's growth strategy. That strategy succeeded — WordPress powers 74% of the detectable web. But the security cost of that success is now quantifiable, and 18,321 is the number.
