WordPress core logged six security vulnerabilities last year; the plugin ecosystem logged 11,334. 1 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%. Each year now adds more new vulnerabilities than the last did. 2 Source 2 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%). 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. 3 Source 3 Patchstack State of WordPress Security 2025 and 2026 reports. Among high-impact, heavily targeted vulnerabilities, the median time from disclosure to mass exploitation is five hours and roughly half (45%) are exploited within 24 hours (2026 report). 43% of vulnerabilities required no authentication, making them exploitable from the public internet with no credential (2025 report, covering 2024 data). For the most heavily targeted flaws, the median time from disclosure to mass exploitation is five hours. More than four in ten vulnerabilities need no authentication at all, so they can be hit straight from the open internet before you have read the disclosure.
Median time from disclosure to exploitation for heavily targeted flaws: five hours. Your patching cadence isn’t the bottleneck. Your vendors’ is.
And the abandoned plugin problem is getting worse, not better. In 2022, 147 plugins were flagged as abandoned. A year later that number reached 827, a 462% increase (Patchstack, 2024). By 2024, WordPress.org removed 1,614 plugins and themes for unpatched security issues (Patchstack, 2025). 4 Source 4 Patchstack State of WordPress Security 2024, covering 2022 and 2023 data: 147 plugins and themes reported abandoned in 2022, rising to 827 in 2023, a 462% increase. Patchstack State of WordPress Security 2025, covering 2024 data: 1,614 plugins and themes removed from the WordPress repository for unpatched security issues. 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. 5 Source 5 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. 6 Source 6 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.” 7 Source 7 Patchstack, EU Cyber Resilience Act guide for open source vendors. Covers classification, obligations, and the 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. 8 Source 8 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 starts SBOM work in its first two weeks, and that plan covers a single plugin from a single vendor. 9 Source 9 Patchstack CRA guide for open source vendors. 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. The deadline is now weeks away.
For a CTO reviewing vendor CRA readiness ahead of September 11, a 30-plugin stack means 30 separate vendor conversations, 30 sets of SBOM documentation to chase 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. 10 Source 10 Sucuri 2023 Hacked Website Threat Report. 39,594 sites cleaned. WordPress 95.5% of CMS infections; Joomla at 1.7%; Magento at 0.6%. Sucuri observed more than 500,000 infected websites in 2024, a figure Patchstack cites in its 2025 report. 11 Source 11 Patchstack State of WordPress Security 2025, citing Sucuri. The count covers calendar year 2024 and is not limited to WordPress.
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. 12 Source 12 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). 13 Source 13 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 removes that class of dependency risk.
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 11, 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. In October 2024, WordPress.org replaced Advanced Custom Fields in the plugin directory with its own fork, on a plugin carrying more than two million active installs. 14 Source 14 WordPress.org, Secure Custom Fields announcement, October 12, 2024. WordPress.org forked Advanced Custom Fields and published the fork in the plugin directory in its place.
Your readiness doesn’t determine your compliance posture. Your vendors’ readiness does. With 46% of new vulnerabilities unpatched at public disclosure today, most vendors will not be meeting 24-hour reporting from day one.
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, and the compliance one has a date attached.
A company starting a vendor readiness review now has weeks, not months, to map 20-30 plugin vendors, assess their CRA readiness, and collect 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. That capacity goes to product security, performance, and the roadmap instead of patch triage, and it walks into September with the vendor-risk question already answered.
The research is free. So is the diagnosis — 60 seconds →