CMS & Web/Comparison
CMS security compared: WordPress, Drupal, Joomla, TYPO3, Ghost and static sites
Six ways to run a website, scored on security process, extension risk, updates, support windows and attack surface. The right choice depends less on the code than on the routine you can keep.
sha256("/cms/cms-security-compared/")Choosing a content management system means choosing a security routine. Every platform in this comparison can run a safe website, and every one of them has been broken into on sites that skipped updates or stacked up extensions. What differs is how much work the safe state takes, how long a version gets fixes and how much code faces the internet. We score six options on those points so you can pick the one your team will actually keep up with.
Seven criteria that decide day to day safety
A (content management system) is the software editors use to change a site without touching code. Its security depends on the people who fix it and on the habits it encourages. We scored each option from 1 to 5 on these criteria, and higher is always better:
- Core security process: a dedicated security team, a clear way to report flaws, published advisories and predictable release days.
- Low extension risk: how much danger add-ons bring, given the size of the ecosystem and any review or coverage rules.
- Update automation: whether security fixes reach the site without a person logging in.
- Long-term support: published end of life dates and how long a version keeps receiving fixes.
- Small : how much code is reachable from the internet while the site runs.
- Admin protection: multi-factor authentication (MFA) and login rate limits out of the box.
- Low maintenance effort: the skill and time needed to keep the site in a safe state.
One pattern holds across all of them: the core is rarely the weakest part. Most publicly reported WordPress vulnerabilities concern plugins and themes rather than WordPress itself, and extensions carry the same kind of risk on the other platforms. A core has a security team. An add-on may have one part-time maintainer, or none. So the size and quality of the extension ecosystem matters as much as the core.
Interactive comparison
CMS platforms compared by security
Editorial scores from 1 to 5 for teams that run their own website, where higher is always better.
Best for publishers and newsletters that need no plugins.
- No server-side plugin layer
- Logins from new devices confirmed by email code
- Login attempts rate limited by default
- Staff users can add scripts, so all must be trusted
- Only the previous major gets LTS fixes
- Self-hosted updates must be started by hand
Best for sites that change rarely and teams comfortable with git.
- No database or login on the live server
- Little to patch at runtime
- Easy to host almost anywhere
- Risk moves to the build pipeline and accounts
- Forms and comments need third party services
- Editors may need a headless CMS
Best for mid-sized sites that want MFA and clear support dates without many add-ons.
- MFA built into the core
- Published bugfix and security end dates
- One click core updates
- Extension quality varies
- Smaller community than WordPress
- Support dates marked as tentative
Best for organisations with agency support that value long, predictable LTS windows.
- LTS with about three years of free fixes
- MFA in the backend core
- Security team covers core and extensions
- Steep learning curve
- Updates usually need a developer
- Extended support after LTS is paid
Best for complex sites with a developer or agency and a deployment pipeline.
- Dedicated security team and monthly release windows
- Advisory coverage shown on each contributed project
- Published release schedule
- Composer based updates need technical skills
- MFA only through contributed modules
- Major upgrades take planning
Best for small teams that want a familiar editor and will keep plugins to a minimum.
- Automatic minor core updates by default
- Large, experienced security team
- Automatic updates per plugin and theme since 5.5
- Only the latest version is officially supported
- Huge plugin ecosystem of uneven quality
- No MFA or login limits in core
All scores in a table
| Criterion | Ghost | Static site generator | Joomla | TYPO3 | Drupal | WordPress |
|---|---|---|---|---|---|---|
| Core security process | ||||||
| Low extension risk | ||||||
| Update automation | ||||||
| Long-term support | ||||||
| Small attack surface | ||||||
| Admin protection | ||||||
| Low maintenance effort |
Editorial assessment as of 31 October 2026. Scores from 1 to 5, higher is better. Your weights only change the order.
WordPress: easy to update, easy to overload
WordPress has a large, experienced security team and a long record of shipping fixes quickly. Minor core releases, which carry security fixes, install automatically by default, and since version 5.5 you can switch on automatic updates for each plugin and theme. The catch is the support policy: only the latest version is officially supported. The security team backports fixes to older branches as a courtesy, but you should not plan around that.
The weak spots are mostly the ones you add. The plugin directory is huge and quality varies widely, from well funded teams to abandoned hobby projects. Core has no built-in MFA and no limit on failed logins, and both the login page and xmlrpc.php are public by default. Each of these is fixable with a few settings and one or two well maintained plugins, which is why WordPress scores high on updates but low on extension risk and admin protection.
Drupal and TYPO3: long support, more engineering
Drupal has a dedicated security team, a security release window on the third Wednesday of each month and a published release schedule. Minor versions arrive roughly every six months, and two minor versions at a time receive security advisories. Contributed modules are covered only if their maintainers opt in, and the project page says so. Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is planned to ship, so Drupal 10 sites need an upgrade plan now.
Drupal core includes , which blocks repeated failed logins, while MFA comes from contributed modules. Updates usually run through , the PHP dependency manager, which suits teams with a developer and a deployment pipeline better than a lone editor.
TYPO3 uses a long-term support () model. TYPO3 v14 LTS was released on 21 April 2026 and receives bug fixes until 31 December 2027 and security patches until 30 June 2029, while v13 LTS is still maintained. After the free LTS period, paid Extended LTS is available. The backend ships with MFA, and the security team publishes advisories for core and for extensions. Like Drupal, TYPO3 is usually built and maintained by an agency or an in-house developer, which shows in the effort score.
Joomla and Ghost: the middle ground
Joomla publishes clear support dates, though the project calls them tentative. The 6.x series, released on 14 October 2025, is planned to receive security fixes until 16 October 2029, and 5.x until 12 October 2027. MFA is built into the core, core updates install with one click from the administrator panel, and the Joomla Security Strike Team handles reports about the core. Extensions vary in quality, as everywhere, but the ecosystem is smaller than that of WordPress.
Ghost is a focused publishing platform built on Node.js. It has no server-side plugin system: you change its look with themes and connect other services through its APIs and webhooks, which removes a whole class of risk. Staff logins from unknown devices must be confirmed with a code sent by email, and login attempts are limited to five per hour per IP address. Self-hosted installs update with one command line call, but someone has to run it.
The current major version is Ghost 6.x. The previous major gets critical fixes as the LTS line, and Ghost 5.x reached end of life in January 2026. Ghost treats every staff user as trusted, including the ability to add scripts, so invite only people you would hand the keys to.
Static site generators: the smallest live surface
A (Hugo, Jekyll, Eleventy and many others) turns templates and text files into plain HTML before deployment. The live server delivers files and runs no CMS code, no database and no login page. That is why this option scores highest on attack surface. There is no single security team, though: each generator is its own open-source project, and your exposure sits mostly in the build tools and themes you pull in.
The risk does not vanish, it moves. The build pipeline, its dependencies, the git hosting account and the deploy keys now hold the power an admin login used to hold. Contact forms and comments rely on third party services, and you still need HTTPS and security headers. Editors without technical skills may need a headless CMS on top, which brings its own login and updates back.
Which one fits whom
| Situation | Good fit | Why |
|---|---|---|
| Small business, one editor, no developer | WordPress with few plugins, or Ghost | Automatic updates and a simple admin, as long as extensions stay few |
| Brochure site that rarely changes | Static site generator | Almost nothing to attack at runtime and little to patch |
| Complex site with roles, workflows and several languages | Drupal or TYPO3 | Fine-grained permissions and predictable support, maintained by a developer or agency |
| Mid-sized site that wants MFA without extras | Joomla | MFA in core and published support dates |
| Newsletter and membership publishing | Ghost | No plugin layer and a focused feature set |
The risk does not vanish with a static site, it moves to the pipeline and the accounts behind it.
Sources and further reading
- WordPress: Securitywordpress.org
- Drupal core release scheduledrupal.org
- Drupal security advisory policydrupal.org
- TYPO3 v14 LTS announcementnews.typo3.com
- Joomla development roadmapdeveloper.joomla.org
- Ghost major versions and LTSdocs.ghost.org
General information, checked on 31 October 2026. Test changes on one system first and keep a way back. Found something outdated? Tell the editors.