CMS Vulnerability Statistics 2026: Security, CVEs & Exploitation Data

Key CMS Vulnerability Statistics for 2026

These figures should not be read as a league table of which CMS is “most vulnerable.” WordPress has a far larger installed base and extension ecosystem than Joomla or Drupal, while vendor disclosure practices and database coverage differ. A defensible CMS vulnerability report therefore needs denominators, source definitions and a clear distinction between core software, extensions, configuration weaknesses and exploited flaws.

What Counts as a CMS Vulnerability?

A CMS vulnerability is a security weakness that affects the content management stack, but the affected layer matters. A flaw in WordPress core is not the same thing as a flaw in a WordPress plugin, and a vulnerability in a Joomla extension should not be counted as a Joomla core vulnerability. The same distinction applies to Drupal contributed modules, commercial CMS add-ons, themes, templates and framework dependencies. Combining all of them into one number may be useful for measuring total ecosystem exposure, but it is not useful for comparing core platform security.

Core CMS vulnerabilities

Core vulnerabilities exist in the main CMS software maintained by the platform project or vendor. They can be especially important because one core flaw may affect a large share of installations using the vulnerable branch. Joomla’s official Security Centre, for example, published several core issues in 2026 involving incorrect access control in web service endpoints and an unrestricted SHTML upload issue. Drupal’s Security Team also published core advisories covering XSS, SQL injection, PHP object injection, SSRF and improper validation. Core vulnerability counts are comparatively clean because the affected product and security authority are usually well defined, but the installed-version distribution still determines real exposure.

Plugin, module, theme and extension vulnerabilities

Third-party components create a much broader attack surface because a CMS installation can combine dozens of independently maintained packages. This is especially visible in WordPress. Wordfence reported 2,213 vulnerabilities added to its intelligence database in Q4 2025 and stated that the majority were plugin-related. That matters because an organization can run a fully patched CMS core while still exposing a vulnerable plugin or theme. ScanTitan’s dedicated WordPress Plugin Vulnerability Statistics research should be used when the question is specifically about the WordPress extension layer rather than CMS platforms as a whole.

Configuration, lifecycle and supply-chain risk

Not every CMS compromise begins with a newly disclosed CVE. Unsupported versions, weak authentication, unsafe file permissions, exposed administrative interfaces and abandoned extensions can keep sites vulnerable long after a patch exists. Supply-chain events add another category because malicious or compromised update infrastructure can affect software that was previously trusted. These risks belong in a CMS security analysis, but they should not be presented as CVE counts. Keeping the categories separate makes the statistics more useful: vulnerability data describes known software weaknesses, while configuration and lifecycle data describe whether an organization remains exposed to them.

CMS Market Share and Security Exposure

CMS market share is not a security score, but it changes the scale of the attack surface. W3Techs reported in September 2026 that WordPress powers 40.7% of all measured websites and 58.9% of sites whose CMS is known. Joomla accounts for 1.1% of all sites and 1.7% of known-CMS sites, while Drupal accounts for 0.7% and 1.0% respectively. Shopify, Wix and Squarespace also hold substantial CMS shares, but their hosted models make vulnerability disclosure and customer patch responsibility different from self-managed open-source platforms.

The denominator problem is central to CMS vulnerability statistics. A platform used by tens of times more websites and supported by a much larger extension marketplace will naturally generate more vulnerability reports and more attacker interest. Raw CVE or advisory totals therefore cannot prove that one CMS is intrinsically less secure than another. They measure a mixture of software complexity, researcher attention, ecosystem size, disclosure maturity and installed exposure. For context on how software vulnerability totals should be interpreted more broadly, see ScanTitan’s Vulnerability Statistics analysis.

CMS Vulnerabilities by Platform

The most useful platform comparison is not a single all-time CVE number. It is a structured comparison of where flaws occur, how vendors classify them, whether exploitation is confirmed and how much of the installed base remains exposed. WordPress data is dominated by third-party plugins and themes, Joomla provides a centralized official security feed for core issues, Drupal separates core from contributed-project advisories, and Craft CMS has published direct incident guidance for exploited vulnerabilities. These differences affect the numbers before any technical comparison even begins.

WordPress vulnerability statistics

WordPress has the largest CMS attack surface by installed base and one of the richest public vulnerability intelligence ecosystems. Wordfence added 2,213 vulnerabilities to its database in Q4 2025, up 19.2% from the prior quarter. It classified 131 as “high threat” vulnerabilities and 100 as “common and dangerous.” At the end of the quarter, 905 of the disclosed vulnerabilities remained unpatched. The same report says most Q4 vulnerabilities required no authentication and that the majority affected plugins rather than core. These figures are Wordfence database statistics, not universal CVE totals, so they should remain attributed to that dataset.

The pattern is more important than the headline total. A WordPress site can have current core software but remain exposed through one outdated extension. Wordfence’s Q4 2025 data counted 658 cross-site scripting records, 611 missing-authorization records, 224 CSRF records and 107 SQL injection records. That concentration shows why extension inventory and version tracking matter as much as the CMS version itself. ScanTitan’s guide to the most common WordPress vulnerabilities provides the technical detail behind the major classes without turning this broader report into a WordPress-only article.

Joomla vulnerability statistics

Joomla operates at a much smaller web footprint than WordPress, but its official 2026 security feed shows continuing core security work. In August 2026, the Joomla Security Centre published CVE-2026-73373 for unrestricted SHTML uploads affecting Joomla CMS versions through 5.4.7 and 6.1.2 under specified ranges. The flaw could lead to code execution on servers configured to execute SHTML files. The same August release cycle also addressed multiple access-control problems affecting web service endpoints. These records demonstrate why a smaller CMS market share does not eliminate core-platform risk.

Joomla’s data also illustrates why severity labels require context. The project separately reports impact, severity and probability, so a flaw with a potentially serious outcome can still receive a lower probability assessment. That is different from treating CVSS as a direct prediction of exploitation. For a deeper platform-specific dataset, ScanTitan’s Joomla Vulnerability Statistics research separates Joomla core from extension vulnerabilities and tracks exploitation-related evidence without mixing the two.

Drupal vulnerability statistics

Drupal’s 2026 security advisories show several important core vulnerability classes. CVE-2026-6365, disclosed in April, was a critical XSS issue in Drupal’s jQuery integration for AJAX modal dialogs. CVE-2026-9082, disclosed in May, was a highly critical SQL injection affecting PostgreSQL-backed sites and could be exploited by anonymous users. The Drupal Security Team later updated the advisory to state that exploit attempts were being detected in the wild. June advisories included a PHP object injection issue, SSRF, cache poisoning and improper upload validation, while July brought additional XSS fixes.

Drupal is also a useful example of disclosure scope. The Drupal project acts as a CVE Numbering Authority and states that CVEs generally apply to Drupal core and contributed projects qualifying for security advisories with more than 10,000 reported installs, with additional cases handled on a reasonable-effort basis. That means a Drupal CVE count reflects the project’s assignment and advisory rules, not every possible weakness in every module. Comparing its raw total directly with a broader WordPress intelligence database would therefore be methodologically weak.

Craft CMS and other platforms

Craft CMS provides one of the clearest recent examples of exploitation moving quickly from disclosure to operational risk. Craft says it received a report concerning the issue behind CVE-2025-32432 on April 7, 2025, released fixed versions on April 10, and found evidence suggesting in-the-wild exploitation by April 17. It then contacted potentially affected license holders. That timeline matters more than a raw count because it shows a one-week transition from patch release to confirmed exploitation evidence.

Umbraco, Sitecore and Adobe Experience Manager introduce another risk dimension: lifecycle and deployment complexity. Enterprise CMS installations often stay on older branches because upgrades require custom code testing, integration work and vendor coordination. A smaller public vulnerability count can coexist with high organizational exposure if unsupported or partially supported versions remain deployed. For that reason, this report does not rank platforms by CVE count alone.

CMS Core vs Plugin and Extension Vulnerabilities

The distinction between core and extension vulnerabilities is one of the most important pieces of CMS security data. WordPress is the clearest case: Wordfence’s Q4 2025 report says the majority of vulnerabilities were plugin-related, and ScanTitan’s existing WordPress research similarly treats plugins as a separate vulnerability population. Joomla’s official Security Centre, by contrast, explicitly labels core and framework issues, while third-party Joomla extensions have their own disclosure channels. Drupal divides core security advisories from contributed-project advisories.

WooCommerce demonstrates this counting problem especially well because it is both a major WordPress plugin and an ecosystem of extensions. A vulnerability in WooCommerce core, a payment extension, a checkout add-on and WordPress itself may all affect an e-commerce site, but they are four different product layers. ScanTitan’s WooCommerce Vulnerability Statistics report keeps those layers separate so an extension flaw is not mislabeled as a WooCommerce core flaw.

The Most Common CMS Vulnerability Types

Across CMS ecosystems, several vulnerability classes recur because content management platforms handle untrusted input, authenticated roles, uploads, templates, database queries and extensible code. Wordfence’s Q4 2025 WordPress dataset gives a concrete distribution: XSS was the largest class at 658 records, followed closely by missing authorization at 611. CSRF accounted for 224 records, sensitive-information exposure for 116, PHP remote file inclusion for 109 and SQL injection for 107. These counts describe one WordPress intelligence dataset and should not be generalized as the exact distribution for every CMS.

The official Joomla and Drupal advisories reinforce many of the same technical themes. Joomla fixed multiple incorrect-access-control issues in 2026, while Drupal published 2026 core advisories for XSS, SQL injection, SSRF, PHP object injection and improper validation. The recurrence across different codebases is not surprising: CMS platforms expose similar security boundaries, including content rendering, user permissions, uploads, database access and remote APIs. What changes by platform is how often each class appears, where it appears and how much exposed software remains deployed.

How Quickly Are CMS Vulnerabilities Exploited?

CMS vulnerabilities can be exploited within days of disclosure, and some are targeted even before defenders have completed patching. Craft CMS provides a documented example: fixed releases for CVE-2025-32432 were published on April 10, 2025, and Craft reported evidence suggesting exploitation in the wild by April 17. Drupal’s May 2026 advisory for CVE-2026-9082 was updated two days after release to state that exploit attempts were being detected in the wild. These examples do not establish a universal CMS exploitation time, but they show why high-impact, internet-facing flaws need rapid triage.

The broader vulnerability environment is moving in the same direction. ScanTitan’s Website Hacking Statistics research provides the attack-side context, while CMS-specific advisories show which software weaknesses are entering that attack surface. The practical lesson is to separate disclosure date, patch date, proof-of-concept availability and confirmed exploitation date. A scanner that only reports CVSS severity can miss the most important timing signal: whether attackers have already started using the flaw.

Which CMS Vulnerabilities Are Actively Exploited?

Confirmed exploitation should receive more weight than raw severity when prioritizing an exposed CMS. Craft CMS directly reported in-the-wild exploitation evidence for CVE-2025-32432. Drupal reported exploit attempts for CVE-2026-9082. WordPress security vendors regularly publish attack telemetry when plugin flaws move into active exploitation. These signals answer a different question from CVSS: not “how bad could this flaw be?” but “are attackers using it now?”

CISA’s Known Exploited Vulnerabilities catalog is useful when a CVE is listed there, but it is not a complete inventory of every exploited CMS flaw. Vendor telemetry, incident-response reports and project advisories can identify exploitation before or outside KEV inclusion. That makes source layering important. For each high-priority CMS finding, defenders should check the vendor advisory, CVE/NVD record, CISA KEV status and relevant threat-intelligence evidence instead of relying on one database.

CMS Vulnerability Severity vs Exploitability

CVSS, EPSS and CISA KEV measure different things. CVSS describes technical severity. EPSS estimates the probability that a published CVE will be exploited in the next 30 days. CISA KEV records vulnerabilities with evidence of exploitation. A CMS flaw can therefore be critical by CVSS but have limited practical exposure, or score lower while still being actively targeted because exploitation is easy and the affected component is widely installed.

The search results for this topic can be misleading because CMS.gov appears prominently for EPSS queries. In that source, CMS means the U.S. Centers for Medicare & Medicaid Services, not Content Management System. Its EPSS guidance is still useful as vulnerability-management material, but it is not a CMS-platform dataset. This entity distinction matters for SEO research and for the final article: a search result containing “CMS” should not be treated as evidence about WordPress, Joomla, Drupal or other content management systems.

For operational prioritization, combine severity with exploitation evidence, internet exposure, authentication requirements, affected asset importance and patch availability. ScanTitan’s guide on how to prioritize vulnerability remediation covers that workflow in more detail.

Why CMS Vulnerability Databases Show Different Numbers

CMS vulnerability databases show different totals because they count different products, records and disclosure scopes. A CVE database may count one standardized vulnerability identifier, while a CMS-specific database may include vulnerabilities that do not yet have CVEs, split affected branches into separate records, or include plugins and themes that the platform’s own security feed does not cover. Vendor advisories may also group multiple technical issues under one security release.

Drupal’s CNA policy is a good illustration. The project says CVEs are generally assigned to core and contributed projects that qualify for a security advisory and have more than 10,000 reported installs, although other cases may be handled. A WordPress intelligence database following a different inclusion policy will not be directly comparable. This is why the source, date and counting method belong beside every CMS vulnerability total.

CMS Vulnerability Trends Over Time

Three trends stand out from the current evidence. First, the extension layer continues to dominate WordPress vulnerability volume. Second, smaller CMS platforms still produce high-impact core vulnerabilities, including exploited SQL injection and RCE-class issues. Third, installed-base concentration is changing. W3Techs shows WordPress CMS market share moving from 60.8% in September 2025 to 58.9% in September 2026, while Shopify rose from 6.7% to 7.7% and Wix from 5.6% to 6.1% over the same period.

That shift does not mean WordPress suddenly became safer or less targeted. It means the CMS market is diversifying while WordPress remains dominant. At the same time, modern CMS environments increasingly include APIs, headless front ends, SaaS components, third-party scripts and commerce extensions. The attack surface is therefore broader than the PHP application or CMS core alone. Statistics based only on core CVEs will capture less of the operational risk than they did when CMS deployments were more self-contained.

What CMS Vulnerability Statistics Actually Tell Us About Risk

CMS vulnerability statistics are most useful when they answer four questions: how much software is exposed, where the weakness lives, whether exploitation is happening and whether a patch is available. A raw count answers only one part of that picture. WordPress can produce thousands of vulnerability records because its extension ecosystem and research coverage are enormous. Drupal can have far fewer records yet still require emergency patching when a highly critical core SQL injection appears. Craft CMS can have a smaller footprint but become urgent when a single RCE is exploited in the wild.

For site owners, the defensible unit of analysis is not “my CMS brand.” It is the exact stack running on the site: core version, extensions, themes, frameworks, exposed endpoints and patch state. That is also why comparisons such as “WordPress has more vulnerabilities than Joomla, therefore Joomla is safer” are weak. They ignore software population, disclosure maturity and third-party code. The better comparison is exposure-adjusted and component-aware.

How to Prioritize CMS Vulnerabilities

Prioritization should begin with asset and version visibility, then layer vulnerability and exploitation data on top. A critical CVE affecting a component that is not installed is not your problem. A medium or high-severity flaw in an internet-facing plugin that is actively exploited may be far more urgent. The workflow below keeps the decision tied to actual exposure rather than vulnerability-feed volume.

1. Inventory the CMS stack. Record the exact core version, plugins, themes, modules, extensions, frameworks and externally reachable administrative or API endpoints.
2. Match versions to current advisories. Check vendor and project security feeds first, then CVE/NVD and specialized CMS intelligence databases.
3. Check exploitation evidence. Review CISA KEV, vendor attack telemetry and public incident reports for signs that the flaw is being used in the wild.
4. Evaluate exploit conditions. Prioritize unauthenticated and remotely reachable flaws ahead of issues requiring privileged access or uncommon configurations.
5. Apply the patch or remove the component. If no fix exists, disable or remove the vulnerable extension where operationally possible rather than leaving known-vulnerable code installed.
6. Verify remediation. Rescan the asset and confirm that the vulnerable version, endpoint or configuration is no longer exposed.

Organizations managing many public websites need automation because CMS extensions change faster than periodic manual reviews can keep up. A website vulnerability scanner can help identify exposed software and web vulnerabilities continuously, but scanner findings should still be interpreted with exploitability, reachability and business impact rather than sorted by CVSS alone.

CMS Vulnerability Statistics Methodology and Sources

This report uses current public data available through September 2026 and prioritizes primary sources wherever possible. CMS usage percentages come from W3Techs. WordPress vulnerability class and quarterly disclosure figures come from Wordfence Intelligence. Joomla core examples come from the Joomla Security Centre. Drupal core examples and CVE assignment policy come from Drupal.org and the Drupal Security Team. Craft CMS exploitation timing comes from Craft’s own security guidance. Competitor reports were reviewed for topic coverage and gaps, but secondary claims were not treated as primary evidence when a first-party source was available.

The report intentionally does not produce an all-time “most vulnerable CMS” ranking. Cross-platform vulnerability totals are not directly comparable unless the databases use the same inclusion criteria, product scope, date range and unit of counting. Market share is included as exposure context, not as a normalization formula. A site using a less common CMS can still face high risk if it runs an exploited, unpatched component. Likewise, a widely used CMS can generate more disclosures because more researchers inspect it.

CMS Vulnerability Statistics FAQ