Content Management Systems (CMSs) power millions of websites worldwide, making them one of the most common ways to publish content online. Because many CMS users have limited cybersecurity expertise, the security protections enabled by default can play an important role in reducing risk.
To determine which platforms provide the strongest out-of-the-box security, we evaluated four popular open-source CMSs: WordPress, Drupal, Joomla, and Ghost. We assessed their default security configurations and scored them accordingly. Historical vulnerability data and ecosystem size were analysed separately to provide context and were not included in the final secure-by-default score.
Key findings:
- WordPress had the weakest out-of-the-box security protections, with a score of 8 out of 100
- Drupal achieved the highest overall score (27.1 out of 100) – note that none of the tested CMSs provided a particularly strong security posture immediately after installation
- Joomla has had the greatest number of disclosed vulnerabilities in the past five years
- Drupal recorded the highest number of high- and critical-severity core vulnerabilities between 2021 and 2025
- WordPress has the largest extension ecosystem, which may increase exposure to security risks associated with third-party plugins
Secure-by-default assessment
The four CMS platforms were assessed immediately following installation to determine their secure-by-default posture. The assessment considered four categories:
- Browser security controls
- Information disclosure
- Authentication security
- API and enumeration exposure
Scores were normalized within each category and weighted to produce a final score out of 100.
Drupal achieved the highest overall score, followed by Joomla, Ghost, and WordPress. However, all four platforms lacked several security controls by default. This is often a deliberate design choice, as some protections – such as multi-factor authentication, Content Security Policies, and advanced access controls – typically require site-specific configuration or are implemented through extensions and plugins after deployment.
1. Browser security controls
Browser security controls help reduce the impact of application vulnerabilities. Six browser-side security mechanisms were assessed: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and Permissions-Policy.
Drupal and Joomla were the only CMSs to enable any of these protections by default. Drupal implemented both X-Frame-Options and X-Content-Type-Options, while Joomla implemented X-Frame-Options and Referrer-Policy. WordPress and Ghost did not enable any of the six tested controls.
Drupal and Joomla therefore achieved the highest browser security scores (10 out of 25), while WordPress and Ghost received no points in this category.
2. Information disclosure
We examined whether information was disclosed to unauthenticated remote users through default HTTP responses and publicly accessible documentation files. It is good practice for default deployments to omit information such as web server details, PHP versions, CMS version information, and documentation files where possible. When exposed, this information enables attackers to fingerprint the underlying platform—either manually or through internet-wide search engines such as Shodan—and determine whether known vulnerabilities or publicly available exploits may apply.
Ghost performed best in this category (with a score of 11.25 out of 15). It did not disclose server versions or PHP versions and did not expose publicly accessible documentation.
Drupal came second, with a score of 3.75 out of 15. Like Joomla, Drupal disclosed its web server version (Apache/2.4.67 Debian). It also disclosed (as did WordPress) its CMS version in the site html. What it didn’t do was have a publicly accessible README (or similar file).
Joomla disclosed its CMS name and version via an exposed public README file. WordPress also had a publicly accessible readme file (at http://localhost:8080/readme.html). Both Joomla and WordPress scored 0 out of 15 in this category overall.
3. Authentication security
Authentication security helps prevent unauthorized access to user and administrator accounts. Strong authentication controls reduce the likelihood that a compromised password will result in a full compromise of the website.
We assessed each CMS on the five controls shown below:
None of the tested CMSs provided built-in MFA, CAPTCHA, or account lockout mechanisms for the administrator account immediately after installation. Without these, attackers can keep trying username and password combinations for as long as they want.
Ghost was the only platform that implemented login rate limiting by default. This is often enough to discourage brute-forcing attempts.
WordPress was the only platform to automatically generate a strong random password during installation. The other platforms had varying requirements for password length and composition. For example, Drupal warned that the password ‘Password123’ was weak, but did not prevent its use.
Joomla required a password of at least 12 characters, but didn’t specify what these characters should be. Ghost rejected ‘Password 123’ for including a ‘common phrase’. It allowed ‘Pa$$w0rd123’.
Overall, WordPress and Ghost scored 8 each, while Drupal and Joomla scored 0. The low scores across all platforms suggest that administrators should not assume modern authentication protections are enabled by default and may need to deploy additional controls.
4. API and enumeration exposure
Externally accessible functionality and information exposed by a system could potentially be targeted by an attacker. Our API and enumeration exposure assessment examined whether remote APIs were enabled by default and whether valid usernames could be identified by unauthenticated users.
All four platforms had predictable admin URLs, which makes it easy for unauthenticated visitors to locate the administration interface and try out credentials.
WordPress and Ghost both exposed remote API endpoints by default. In WordPress, for example, the XML-RPC interface was enabled by default.
XML-RPC provides remote procedure call functionality for WordPress applications and integrations but has historically been associated with brute-force amplification and pingback abuse.
Both platforms also allowed unauthenticated user enumeration. In WordPress, author identities could be identified through author archive URLs – for example, by entering http://localhost:8080/?author=1
In Ghost, this was possible via http://localhost:8083/author/admin/
Attackers could then test whether an author name corresponded to an admin email address. In Ghost, invalid email addresses were flagged as such.
Overall, Drupal and Joomla achieved the strongest scores in this category (13.3 each), while Ghost and WordPress scored 0.
Summary – Which CMS is the most secure by default?
The results indicate that none of the tested CMSs provided a comprehensive set of security controls immediately after installation. However, clear differences were observed in the extent to which each platform prioritized secure defaults.
Drupal achieved the highest overall score primarily because it implemented multiple browser security controls and presented a relatively limited attack surface. Joomla performed similarly, although it exposed more information and did not implement X-Content-Type-Options by default.
Ghost disclosed less information about its underlying technology stack and implemented login rate limiting, but lacked virtually all browser security headers and exposed both remotely accessible API endpoints and user information.
WordPress achieved the lowest score. Although it generated a strong password during installation, it lacked browser security controls, exposed significant platform information, enabled remotely accessible API endpoints, and allowed unauthenticated user enumeration. These findings suggest that WordPress places greater reliance on post-installation hardening and optional security plugins than the other platforms tested.
Overall, Drupal demonstrated the strongest secure-by-default posture in this assessment, followed by Joomla, Ghost, and WordPress.
Regardless of platform choice, administrators should review authentication settings, deploy MFA where available, configure appropriate security headers, remove unnecessary extensions, and keep the CMS and its plugins fully patched.
Vulnerability history
While the preceding sections evaluated the default security controls provided by each CMS, these controls do not necessarily reflect how platforms perform when exposed to real-world security threats. To provide additional context, a historical vulnerability analysis was conducted using publicly disclosed vulnerabilities affecting the core CMS products.
Joomla recorded the highest number of disclosed core vulnerabilities between 2021 and 2025, with 67 CVEs. Drupal followed with 57, while WordPress and Ghost recorded substantially fewer vulnerabilities with 26 and 20, respectively.
Drupal and Joomla also exhibited the greatest concentration of serious vulnerabilities. Drupal recorded 25 high- or critical-severity vulnerabilities. Joomla recorded 23. WordPress recorded only seven high- or critical-severity vulnerabilities during the same period. Ghost recorded the smallest number of disclosed vulnerabilities overall – 4 critical severity and 4 high severity.
Note that these findings should be interpreted alongside the secure-by-default assessment rather than as a standalone measure of security. Vulnerability disclosure rates are influenced by factors beyond the inherent security of the CMS itself – such as platform popularity, researcher attention, codebase size, and vulnerability reporting practices.
Ecosystem size
While this study focuses primarily on the security of default CMS installations, the wider software ecosystem can also influence a platform’s security profile. Extensions, plugins, and modules provide additional functionality but may increase complexity and introduce vulnerabilities that are not present in the core software. The size of each CMS ecosystem was therefore examined to provide context for differences in adoption, extensibility, and potential exposure to third-party security risks.
WordPress (~67,000 plugins) and Drupal (~56,000 modules) have substantially larger extension ecosystems than Joomla (~5,000 extensions) and Ghost (~100 integrations). While this provides extensive functionality, it also increases the potential attack surface associated with third-party plugins. Ghost offered the smallest ecosystem, potentially reducing exposure to vulnerabilities introduced through third-party extensions.
Methodology
Each CMS was deployed in a separate Docker container on a Windows 11 host using Docker Desktop. Fresh installations of WordPress, Drupal, Joomla, and Ghost were created using their official Docker images and default installation settings. Each CMS was configured on a separate local port and assessed immediately after installation. No additional plugins, modules, extensions, reverse proxies, web-server hardening measures, or third-party security tools were installed unless required for the installation process.
The following settings were used for each CMS during installation:
Ghost Settings:
Site Title: Ghost Security Test
Full name: admin
Username: admin
Password: Pa$$w0rd123
Email: test@example.com
database__client: mysql
database__connection__host: db
database__connection__user: ghost
database__connection__password: password
database__connection__database: ghost
Joomla! Settings:
Site Title: Joomla Security Test
Super User name: admin
Username: admin
Password: Password1234
Email: test@example.com
JOOMLA_DB_HOST: db
JOOMLA_DB_USER: joomla
JOOMLA_DB_PASSWORD: password
JOOMLA_DB_NAME: joomla
WordPress settings:
Site Title: WordPress Security Test
Username: admin
Password: leave the generated one
Email: test@example.com
Search engine visibility: left unchecked
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: root
WORDPRESS_DB_PASSWORD: password
Drupal settings:
Site name: Drupal Security Test
Site email: test@example.com
Username: admin
Password: Password123
DRUPAL_DATABASE_HOST: db
DRUPAL_DATABASE_NAME: drupal
DRUPAL_DATABASE_USERNAME: drupal
DRUPAL_DATABASE_PASSWORD: password
Security tests for the Secure-by-default Assessment were split into four groups and weighted accordingly. Authentication security was assigned the highest weighting (40%) because weaknesses in authentication can directly result in unauthorised administrative access and full site compromise. Browser security controls were weighted at 25% because they help mitigate the impact of common web application attacks within users’ browsers. API and enumeration exposure was weighted at 20% as exposed functionality and user information can increase an attacker’s opportunities for reconnaissance and exploitation. Information disclosure was weighted at 15% because, while exposed version and configuration information can assist attackers, it generally represents a lower risk than weaknesses that directly enable compromise. The weighting scheme was designed to reflect the relative security impact of each category rather than the number of individual tests within it.
Vulnerability data covering the period 2021 to 2025 were collected programmatically from the National Vulnerability Database using its CVE API 2.0. Each CMS was queried using its core-product Common Platform Enumeration identifier rather than a keyword search. This reduced the inclusion of vulnerabilities associated solely with third-party plugins, modules, themes, and extensions. The collected fields included the CVE identifier, CWE classification, vulnerability type, CVSS base score and version, severity, publication date, description, status, and references. The records were stored in CSV and JSON dictionary formats for subsequent analysis. Where multiple CVSS assessments were available, the most recent supported CVSS version was selected, with NVD assessments prioritised where available.
To assess ecosystem size, the number of extensions available for each CMS was obtained from the official extension repositories maintained by the respective projects. For WordPress, plugins were counted using the WordPress Plugin Directory; for Drupal, contributed modules were counted using Drupal.org; for Joomla, extensions were counted using the Joomla Extensions Directory; and for Ghost, integrations were counted using the Ghost Integrations Directory.