11,334 New WordPress Vulnerabilities in One Year — and a September 2026 Deadline

WordPress core logged six security vulnerabilities last year; the plugin ecosystem logged 11,334. ¹ Source 1 Patchstack State of WordPress Security 2026. Covers calendar year 2025 data. 91% of all vulnerabilities found in plugins, with only 6 in WordPress core. ×

That ratio tells you where the risk actually lives. Not in the platform you chose, but in the 20 or 30 plugins your site depends on to function. Each plugin ships with a different developer behind it and a different patching schedule — and 46% of last year’s new vulnerabilities went public before any patch existed.

And starting September 11, 2026, the EU Cyber Resilience Act turns that patching gap into a regulatory one.

The vulnerability curve is steepening, not flattening

Most security conversations treat vulnerabilities as a static number. The WordPress ecosystem breaks that frame. The growth rate itself is accelerating.

The annual growth rate has risen three years running — 24%, then 34%, then 42% — so each year adds more new vulnerabilities than the last did. ⁸ Source 8 Patchstack State of WordPress Security 2024, 2025, and 2026 reports. New vulnerabilities by year: 5,948 in 2023 (+24%), 7,966 in 2024 (+34%), 11,334 in 2025 (+42%). Cumulative total through 2025: 64,782 known vulnerabilities across the ecosystem. × The 2025 figure was 11,334. If the trajectory holds, 2026 will produce somewhere north of 16,000 new ones — though the curve could flatten or steepen depending on how quickly the ecosystem responds.

This is technical debt accruing compound interest: each year’s exposure grows faster than the last. You can’t model it as a stable budget line.

The distribution matters too. Ninety-one percent of those vulnerabilities sit in plugins. Only six were in WordPress core. The people who built the platform you chose did a reasonable job securing it. The problem is everything else you had to bolt on to make it useful.

The patch gap is outside your control

Even if your team runs updates the moment they land, nearly half the patches arrive late.

Forty-six percent of new vulnerabilities had no patch available when they went public — the flaw was already known, documented, and circulating before any fix existed (Patchstack, 2026). Your update-on-release policy is only as good as the slowest vendor in your stack.

The exploit window is punishing: once a flaw is public, you have hours, not days, to react — and often no way to react at all, because the attack needs no login. ⁷ Source 7 Patchstack State of WordPress Security 2025 and 2026 reports. Median time from disclosure to active exploitation: 5 hours (2025 data). 45% of vulnerabilities exploited within 24 hours of disclosure. 43% required no authentication — exploitable from the public internet with no credential (2024 data). × The median time from a vulnerability going public to active exploitation is five hours. Nearly half the credential-free flaws can be hit straight from the open internet, before you’ve read the disclosure.

And the abandoned plugin problem is getting worse, not better. In 2022, 147 plugins were flagged as abandoned. By 2024, that number had grown to 827, a 462% increase (Patchstack, 2025). ¹ Source 1 Patchstack State of WordPress Security 2025 report. Abandoned plugin data covers the 2022-2024 period. × Each abandoned plugin is code that will never be patched, running on production sites, accumulating vulnerabilities indefinitely. Responding to all of this is a real budget line, too — we’ve priced the maintenance burden at $7,200–$27,000 a year in developer hours alone.

Across 2,000-plus website projects, the pattern I’ve seen has been remarkably consistent: the security budget watches the firewall, and the incident walks in through a plugin somebody installed three years ago and forgot was there.

One data point captures the scale of supply chain risk: in 2023, 21% of all new WordPress vulnerabilities traced back to a single flaw in the Freemius framework, a library used by hundreds of plugins. ¹ Source 1 Patchstack State of WordPress Security 2024 (covering 2023 data). The Freemius framework vulnerability created over 1,200 individual plugin vulnerabilities from a single root cause. × One dependency. Over 1,200 vulnerabilities. That’s not a freak incident — it’s what happens when your architecture is a mesh of independent, opaque supply chains.

Does the EU Cyber Resilience Act apply to WordPress plugins?

Yes. The EU CRA (Regulation 2024/2847) classifies commercial plugin developers as manufacturers with full cybersecurity obligations. Any plugin that charges for premium features, sells support, or earns marketplace revenue falls in scope. Starting September 11, 2026, those manufacturers must report actively exploited vulnerabilities to EU authorities within 24 hours.

The CRA entered into force on December 10, 2024. ² Source 2 EUR-Lex Regulation EU 2024/2847. Phased implementation per Article 71. × Its obligations phase in over three years, but the first high-impact milestone is September 11, 2026: Article 14 reporting obligations become mandatory. From that date, manufacturers of commercial software products must notify EU authorities on a compressed timeline:

• 24 hours: Early warning to the EU’s cybersecurity authorities (the national incident-response teams and ENISA, the EU cybersecurity agency)
• 72 hours: Detailed notification with exploit nature and corrective measures
• 14 days: Final report after a fix is available

The word “manufacturer” is the key. Patchstack’s compliance analysis confirms: “WordPress plugin and theme developers must comply with the CRA.” ³ Source 3 Patchstack CRA Compliance Guide for WordPress. Covers classification, obligations, and 90-day preparation plan. × Any plugin with commercial activity qualifies. Premium versions, paid support, and marketplace monetization all trigger manufacturer classification.

The exemption window is narrow. Only individual hobbyist developers with zero commercial activity, no paid services, and no business entity behind the code fall outside scope. The plugin ecosystem that mid-market companies depend on is overwhelmingly commercial.

Penalties for non-compliance: up to €15,000,000 or 2.5% of worldwide annual turnover for essential cybersecurity requirement violations. EU authorities can order plugins removed from distribution platforms accessible to EU users.

The SBOM problem nobody has scoped

The CRA also requires every commercial software product to include a Software Bill of Materials — a formal inventory of every component and dependency. ² Source 2 CRA Article 3(39), Article 31, Annex VII. × That SBOM requirement is where the plugin architecture creates a compliance surface your team can’t consolidate.

For a typical mid-market WordPress installation with 20 to 30 plugins, your organization depends on 20 to 30 vendors each producing their own SBOM. Each plugin carries its own PHP and JavaScript dependency chains that the CRA requires documenting. Patchstack’s 90-day CRA preparation plan devotes the first two weeks exclusively to SBOM creation — and that’s for a single plugin from a single vendor. ³ Source 3 Patchstack CRA compliance guide. The 90-day preparation plan covers SBOM creation, vulnerability disclosure workflow setup, and incident reporting procedures. ×

Most plugin developers have never been asked to produce an SBOM. The gap between what the CRA requires and what the ecosystem can actually deliver spans months of preparation — months that are running out.

For a CTO preparing a September 2026 compliance review, a 30-plugin stack means 30 separate vendor conversations, 30 sets of SBOM documentation to receive and validate, and 30 points of failure if any vendor misses the deadline. A single-framework architecture compresses that to one.

A modern static architecture built on a single framework with one package manager has exactly one dependency tree to document. The compliance surface shrinks by an order of magnitude, not because the technology is inherently more secure (though the reduced attack surface helps), but because the architecture consolidates dependencies instead of scattering them across dozens of uncoordinated vendors.

What the infection data tells the board

The vulnerability data shows up in infection rates exactly where you’d expect. WordPress accounted for the overwhelming majority of all hacked sites that Sucuri, a website security firm, cleaned in 2023 — far more than every other content platform combined. ⁴ Source 4 Sucuri 2023 Hacked Website Threat Report. 39,594 sites cleaned. WordPress 95.5% of CMS infections; Joomla at 1.7%; Magento at 0.6%. × Patchstack reported over 500,000 WordPress sites infected in 2024. ⁶ Source 6 Patchstack State of WordPress Security 2025. Infection count covers calendar year 2024. ×

The infections trace straight back to the patch gap. Nearly four in ten compromised sites were running outdated software when they were breached, and almost half had a hidden backdoor installed for repeat access. ¹⁰ Source 10 Sucuri 2023 Hacked Website Threat Report. Of sites cleaned, 39% were running outdated software at the time of compromise; 49.21% had at least one backdoor installed. ×

The cost of a breach at this scale is well-documented. IBM’s 2025 data puts the global average at $4.44M (IBM, 2025). ⁵ Source 5 IBM Cost of a Data Breach Report 2025. × A mid-market company won’t approach that average, but incident response, forensics, customer notification, and recovery costs add up quickly even at a fraction of enterprise scale.

The question for a CTO isn’t whether WordPress can be secured. Anything can be hardened with enough effort and budget. The real question is whether securing a 30-plugin architecture with 30 independent vendor patching cadences is the best use of your security team’s time — when the alternative is an architecture that eliminates the problem structurally.

The architecture decision the CRA forces

Before the CRA, you could accept WordPress’s security overhead as a known cost of doing business. Your team patches what it can, runs a web application firewall to screen malicious traffic, monitors for intrusions, and absorbs the residual risk. That posture was defensible when the only consequence of a slow-patching vendor was operational.

The CRA changes the equation. Starting September 2026, slow-patching vendors aren’t just an operational risk — they’re a compliance exposure. If a plugin in your stack has an actively exploited vulnerability and its developer doesn’t report within 24 hours, you’re running non-compliant software in production. The plugin dependency chain is a SaaS supply chain, and the CRA treats it as one. And the update channel that delivers those plugins has been repurposed before — WordPress.org itself seized and replaced a major plugin on millions of sites in October 2024.

Your readiness doesn’t determine your compliance posture. Your vendors’ readiness does. With 46% of new vulnerabilities unpatched at public disclosure today, the question of how many vendors will meet 24-hour CRA reporting deadlines by September answers itself.

The broader trend of enterprises replacing SaaS tools is driven partly by exactly this: the security burden of maintaining a stack whose risk surface you can’t control. WordPress’s 42% year-over-year vulnerability growth puts that dynamic on a steeper curve than most platforms. The plugin ecosystem is also one of the five lock-in mechanisms that make WordPress migrations progressively more expensive the longer they’re deferred — and the security compound makes that switching cost grow every quarter you stay.

For companies evaluating their architecture, the CRA creates a useful forcing function. A 30-plugin WordPress stack means 30 independent compliance surfaces and 30 vendor CRA readiness assessments you can’t control. A modern architecture with controlled dependencies consolidates all of that into one surface you own. The security argument and the compliance argument now point the same direction. Both have a September deadline attached.

Companies that start a CRA compliance audit in Q3 2026 face a sprint to map 20-30 plugin vendors, assess their CRA readiness, and document each SBOM. Companies that started that work on a modern architecture with one dependency tree already have it done. The decision is about which problem you want to own.

And the gain compounds past compliance. A one-tree architecture hands back the hours your team currently spends chasing plugin CVEs — capacity that goes to product security, performance, and the roadmap instead of patch triage — and walks into the September audit with the answer already written.