Drupal vs WordPress security

Drupal vs WordPress security: which project fits your risk model

For a regulated team, the first question is who ships the fix and how it reaches your servers. Drupal's security team handles core vulnerabilities, and security releases arrive on the third Wednesday of the month, which gives your patch process a fixed date to plan around. Contributed modules receive advisory coverage only when their maintainers opt in, so each module in your build needs its own check. WordPress's Security Team, which includes more than 50 trusted experts, fixes responsibly disclosed vulnerabilities in bugfix releases. WordPress relies on background automatic updates, and the team backports critical fixes to older versions as a courtesy, even though only the latest version is officially supported. This comparison looks at process and hardening, and it does not declare either project the safer one.

Core is only part of your exposure. On WordPress, plugins and themes receive automatic updates by default only in special cases that the WordPress.org API determines, and the security team controls that mechanism to patch critical vulnerabilities, so most plugin updates still need a named owner. On Drupal, contributed modules are covered by advisories only when opted in, so your module inventory is the main control point. Platform versions matter as well. Drupal 11 requires PHP 8.3 or later, and Drupal 10 reaches end of life on December 9, 2026. WordPress recommends PHP 8.3 or greater and MariaDB 10.11 or MySQL 8.0. Confirm your PHP and database versions against each project's requirements before you commit to a hosting stack.

Turn this into written decisions before you pick a stack. Build an inventory of every module, theme and plugin with its maintainer, advisory status and last release, and assign one owner to each. Decide which WordPress plugins, if any, your policy allows to auto-update, and which Drupal security releases must pass staging tests before production, given the first-Wednesday bugfix and third-Wednesday security cadence. Ask any implementation partner to show how they will track advisories, test patches, roll back changes and prepare for Drupal 10 end of life on December 9, 2026. Regulated teams should keep these records as evidence for their assessors.

How each project handles security, part by part

This table compares how Drupal and WordPress handle vulnerability response, release timing, automatic updates, supported versions, runtime requirements and licensing. Read each row as a question to put to your own patch process: where the fix comes from, when it arrives and who applies it. The main takeaway is that WordPress automates more of core and critical plugin patching, while Drupal gives a predictable release calendar and leaves contributed module updates to your team.

Area	Drupal	WordPress
Security team	The Drupal Security Team handles reports for core and contributed projects. Confirm how contributed module advisories reach your team in your own environment.	The WordPress Security Team includes more than 50 trusted experts, including lead developers, security researchers and key contributors.
Release timing	Bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday, per the core release schedule.	Security fixes ship in bugfix releases. Confirm the current cadence on the WordPress releases page before planning a window.
Supported versions	Drupal 10 reaches end of life on December 9, 2026. Drupal 12 is scheduled for the week of December 7, 2026.	Only the latest version is officially supported. WordPress 7.1 is the current series, and only its most recent release (7.1.3, October 6, 2026) is actively maintained.
Backports to older versions	Older supported Drupal branches receive security fixes on their own schedule. Confirm the end-of-life date for the branch you run.	The Security Team backports fixes to older versions as a courtesy, so older sites can receive critical fixes through auto-updates.
Automatic core updates	Core updates are applied by your team or your deployment pipeline. Plan a tested update path for each security release.	Automatic background updates were introduced in WordPress 3.7. Sites created since WordPress 5.6 have automatic major release updates enabled by default.
Plugin and module updates	Contributed modules are updated by your team against advisories. Contributed projects must opt in to advisory coverage, so confirm which modules you depend on are covered.	Plugins and themes receive automatic updates only in cases the WordPress.org API selects, which the Security Team controls to patch critical vulnerabilities.
PHP requirement	Drupal 11 requires PHP 8.3 or later. Drupal 12 requires PHP 8.5 or later, so plan PHP upgrades alongside core upgrades.	WordPress.org recommends PHP 8.3 or greater for hosting WordPress.
Database requirement	Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later.	WordPress.org recommends MariaDB 10.11 or greater or MySQL 8.0 or greater.
License	GPL-2.0-or-later for Drupal and contributed files hosted on Drupal.org. There is no paid edition of Drupal itself.	GPLv2 or later from the Free Software Foundation.

How Drupal's security team and release windows work

The Drupal Security Team handles vulnerability reports for Drupal core and coordinates fixes before they are published, so administrators can plan around a predictable schedule rather than reacting to disclosures as they arrive. Core security releases land on the third Wednesday of the month, while bugfix releases come out on the first Wednesday, according to the Drupal core release schedule. Security advisories also cover contributed projects whose maintainers have opted in, which means the advisory feed you need is broader than core alone. Read the team's process on the Drupal Security Team page before you set your monitoring scope.

Acting on that schedule is your job, not the vendor's. Subscribe to Drupal security advisories for core and for every contributed module in your composer.lock, assign an owner to read them, and block a recurring update window that falls after the third Wednesday of each month. Test contributed modules in a staging copy before production, because a security fix in a module can change configuration or database updates that core testing never touches. Confirm with your partner or hosting provider how emergency patches are applied outside the normal window.

Drupal 7 security support ended on January 5, 2025, so any Drupal 7 site still in production has no community security coverage. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Those contracts carry their own terms, scope and cost, which you should compare in writing against a migration plan. Treat them as a bridge to a supported version, not a long-term security position.

Where the real risk sits in plugins and modules

Core releases from either project are only part of the exposure. Most incidents on self-hosted sites start in code the team added or chose: contributed modules, plugins, themes, custom code, the PHP and database versions underneath, and the server configuration around them. Each card below names the control your team owns and what to confirm before you commit.

Contributed Drupal modules

Contributed modules are maintained by individual maintainers and teams, and their security coverage depends on whether the project opts into the Drupal Security Team's advisory process. Check each module's maintenance status, its release history and whether it is covered by advisories before you install it. Keep a written inventory of every contributed project, its version and its owner, and confirm with the module's project page how it receives security fixes.

WordPress plugins and themes

Core WordPress receives automatic background updates, but plugins and themes are only auto-updated in special cases chosen through the WordPress.org API. Everything else waits for your team to apply it, so a plugin you installed years ago can remain unpatched while core stays current. Review your plugin and theme list monthly, remove anything unused, and confirm which updates your site applies automatically before relying on that behavior.

PHP version lag

Both platforms depend on the PHP runtime, and falling behind it leaves the site on language versions that no longer get fixes. WordPress.org recommends PHP 8.3 or greater, while Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Your team owns the runtime upgrade schedule on the server, so test each target version against your modules and plugins in staging before moving production.

Database versions

Database engines reach end of support on their own timetables, separate from the CMS. WordPress.org recommends MariaDB 10.11 or greater or MySQL 8.0 or greater, and Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later and PostgreSQL 16 or later. Confirm which database version your hosting provider offers, schedule its upgrades, and check that your Drupal or WordPress version supports the target before moving.

Custom code

Custom modules, themes and code snippets written for one site fall outside any project's advisory process, so the team that wrote them owns every fix. Drupal custom modules call core APIs that can change between major versions, and WordPress custom plugins may depend on functions that are deprecated over time. Keep custom code under version control, run static analysis and a code review on changes, and assign a named owner for each component.

Hosting and server configuration

The web server, file permissions, TLS settings, backups and admin access paths determine how far an exposed plugin or module can reach. Restrict administrative login paths, limit write access to the code directory where your deployment model allows it, and separate staging from production credentials. Confirm with your hosting or platform team who patches the operating system, the web server and the database, because those layers are often outside the CMS vendor's responsibility.

What hardening each platform needs

Drupal hardening starts with version choice, because the supported core line decides which PHP runtime and database server you can run. Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Drupal 10 reaches end of life on December 9, 2026, after which it receives no new releases, so treat a Drupal 10 migration as a security task alongside feature work. Review the Drupal core release schedule when you set your dates.

Pick the PHP line deliberately: Confirm that your host offers PHP 8.3 or later for Drupal 11, or PHP 8.5 or later for Drupal 12, before you choose a target core version.
Match the database to the requirements page: Drupal 11 supports MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later and SQLite 3.45 or later. Replace older database servers before the core upgrade, not during it.
Plan around the release calendar: Bugfix releases come out on the first Wednesday of each month and security releases on the third Wednesday. Keep a maintenance window ready for an out-of-cycle patch.
Inventory and prune modules: Record every contributed module with its version and maintainer, and remove the ones you no longer use. Confirm with your team which contributed projects are covered by security advisories for your site.

Check that staging runs the same core, PHP and database versions as production before each release window.

How to test each platform's patch process in your environment

This sequence shows you how to measure what a security patch costs you on Drupal and on WordPress in your own environment, and what evidence you keep afterward. Run it on staging before you rely on either platform's update path.

Inventory core, extensions and runtime versions
Record the installed Drupal or WordPress core version, every contributed module or plugin with its version and whether it is a custom build, and the PHP version, web server and database version your site runs. Your platform or engineering lead does this, usually by exporting the Composer lock file for Drupal or the plugin list for WordPress. You know the step is done when a single inventory file matches what production reports, and every item has an owner who can approve its update.
Confirm the PHP and database floor for the target release
Compare the inventory against the requirements for the release you would move to, not only the one you run today. For Drupal, check the PHP requirements page for your target major version. For WordPress, compare against the recommended PHP and MariaDB or MySQL versions on the requirements page. Flag any mismatch in the inventory, because a security release that needs a newer PHP or database turns into a platform upgrade. Done when each gap is either closed or logged as a blocker with an owner.
Map advisories to the projects you actually run
Subscribe to the Drupal Security Team advisories and the WordPress security announcements, then match each advisory against your inventory from step one. For Drupal, confirm whether the affected contributed project is one you have opted into receiving advisory coverage for. For WordPress, confirm whether the plugin is in the WordPress.org directory and whether it is covered by the security team's backports. Record for each applicable advisory the project, the fixed version and the date you became aware of it. Done when every installed project has a status: not affected, patched on staging, or open with a reason.
Apply and time a security patch on staging
Take a production-like copy of the site, apply the core and contributed or plugin updates that fix the advisory, and record the steps you ran: composer or admin update, database updates, cache rebuilds and any configuration changes. Time each step and note which ones needed a person. Use a recent security release for each platform, because the process you test should match the one you will run under pressure. Done when the staging site passes your smoke tests and you have a written log of effort, manual steps and failures.
Check what auto-updates will and will not apply
On the WordPress side, review the automatic update settings for core minor and major releases, plugins and themes, and confirm which of them are enabled on production. Note that WordPress applies plugin and theme auto-updates only in the special cases the WordPress.org API flags for critical fixes, so you must still track the rest yourself. On the Drupal side, confirm that no unattended update path exists and that each module update goes through your review and release process. Done when you have a table showing, for each component, whether it updates automatically, on what trigger, and who is notified.
Confirm the release windows in your change calendar
Map the Drupal bugfix and security release days from the core release schedule and the WordPress release cadence onto your change calendar, so security patch work has a fixed slot. Ask your change board to confirm that an out-of-cycle patch path exists for a critical advisory and who approves it. Done when the calendar shows the next expected windows, the approver for an emergency change, and the rollback owner, all recorded in the change policy.
Record evidence for the audit file
Save the inventory, the advisory mapping, the staging test log, the auto-update configuration and the change approvals in one folder tied to each release. Include the commands or screenshots that show versions before and after, and the rollback test result. Ask your auditor or compliance lead which controls this evidence supports, because DeployOpen prepares evidence but does not issue audit opinions. Done when an independent reviewer can trace one advisory from disclosure to a verified production version using only this folder.

Questions buyers ask about Drupal and WordPress security

Which has fewer vulnerabilities, Drupal or WordPress?

Neither project is safer because it reports fewer vulnerabilities, so the useful comparison is process: how issues reach you, how fast fixes ship, and who carries the work when a fix affects your site. Drupal core ships security releases on a fixed schedule, and the Drupal Security Team coordinates disclosures for core. WordPress fixes responsibly disclosed vulnerabilities in bugfix releases, and its Security Team includes more than 50 trusted experts. For most sites, risk sits less in the core than in contributed modules and plugins, because each third-party extension is code you chose to run. Count the extensions you depend on, check whether each one is still maintained, and judge both platforms by how quickly their ecosystems patch what you actually installed.

Are WordPress automatic updates enough to keep a site secure?

No. Automatic background updates have been part of WordPress since version 3.7, and since WordPress 5.6 newly created sites have automatic major release updates enabled by default. Plugins and themes are handled differently: by default, WordPress applies automatic updates to them only in special cases determined through the WordPress.org API, which the security team controls to patch critical vulnerabilities. Only the latest WordPress version is officially supported, although the Security Team backports critical fixes to older versions as a courtesy. A site with many plugins still needs someone to watch advisories, test updates in staging and remove abandoned extensions. Auto-updates shorten the exposure window for core flaws, but they do not replace monitoring of your plugin inventory.

What does Drupal's Wednesday release schedule mean for staffing?

It means someone must be available on a predictable calendar, because the timing of patches is known in advance. According to the Drupal core release schedule, bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday. Your team needs a named owner to read each release, decide whether it applies, and deploy it to staging and then production within your own change window. Plan for the new major versions too: Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, with PHP 8.5 or later required. Ask your provider or internal team to show how release days, testing and approvals are covered when the person who usually does this is unavailable.

What hardening work does each platform need, and who does it?

Both platforms need a documented baseline, and the owner of that baseline is your team, your hosting provider or an implementation partner under a written scope. Drupal hardening usually starts with a supported PHP version (Drupal 11 requires PHP 8.3 or later), a supported database such as MariaDB 10.6 or later or PostgreSQL 16 or later, and a module review.

Confirm each contributed module is maintained and needed.
Connect single sign-on through the SAML Authentication or OpenID Connect contributed modules where your identity provider requires it.
Restrict administrative paths, file permissions and update access.

WordPress hardening centers on PHP 8.3 or greater, MariaDB 10.11 or greater or MySQL 8.0 or greater, a short list of plugins, restricted admin access and a decision on which automatic update classes to allow. Document each choice so the next person can audit it.

Can our own team run Drupal or WordPress security in-house?

Many teams can, provided they have the skills and capacity for the work, not just the software. Running either platform securely requires administration of PHP, the web server, the database, backups and staging, plus someone who can read security notices and make the update decision. Drupal adds a predictable release calendar and more dependence on contributed modules, while WordPress adds a large plugin inventory that must be reviewed continuously. If you run Drupal 7, be aware that Drupal 7 security support ended on January 5, 2025, and the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Ask yourself who covers releases during leave and who signs off on emergency patches.

What would a DeployOpen engagement scope, and what drives the cost?

A DeployOpen engagement is fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts, and that document is the basis for the quote. Work can cover a hardening baseline, update and rollback runbooks, backup and restore setup, identity integration, documentation and security testing of the application and its infrastructure. Compliance work prepares systems and evidence for an assessment, but independent auditors issue any attestation. Cost is driven by the number of sites, the count and state of contributed modules or plugins, the number of integrations, the hosting environments involved and the depth of testing. Ongoing upgrades and continuous testing are available as retainers. To get an accurate quote, prepare an inventory of sites and extensions, target versions, environments, compliance drivers and the access your team can give.

When security should decide between Drupal and WordPress

Security process should decide this choice when your organization must show a documented patch cycle to auditors or regulators, and when you cannot accept an update landing on production without a planned window. Drupal fits that condition better. Its Security Team publishes advisories on a fixed schedule: bugfix releases come on the first Wednesday of each month and security releases on the third Wednesday, according to the Drupal core release schedule. That cadence lets change boards, testers and on-call staff plan around known dates. The advantage matters only if you run a supported major version and can take a release on a known day. Confirm which contributed modules you depend on are covered by advisory coverage, since that coverage applies to opted-in projects, and assign an owner to watch the advisories for each module you run.

WordPress suits a different condition: a team that accepts background updates for core and a large plugin estate that it vets carefully. Automatic background updates have been part of WordPress since version 3.7, and sites created since WordPress 5.6 have automatic major release updates enabled by default, according to the WordPress advanced administration handbook. The WordPress Security Team also backports critical fixes to older versions as a courtesy, though only the latest version is officially supported. The catch is plugins and themes. By default, WordPress applies automatic plugin and theme updates only in special cases chosen through the WordPress.org API, so most plugin risk stays with you. A team choosing WordPress for security reasons should record each plugin's maintainer, last release date and install count before approval, and should decide who reviews plugin changes between releases.

Whichever platform you choose, PHP and database requirements apply in the same way and do not separate the two on their own. WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, according to its requirements page. Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. Before you commit, confirm with your platform team that your PHP runtime and database versions are supported and patched, and that your hosting image receives security updates for them. Also ask who on your side will own the web server, PHP runtime and database patches, because those layers are often the first place a regulated audit finds a gap.

How DeployOpen helps evaluate and harden your CMS

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Drupal or WordPress estate, that means working from your actual module and plugin inventory, your update policy and your hosting stack, not from a generic checklist.

How we scope

Inventory of Drupal core, contributed modules and custom code, or WordPress core, plugins and themes, with each item's source and maintenance status
Written decision on which Drupal advisory coverage to opt into and how Wednesday release windows feed your patch process
Agreed hardening baseline for PHP version, database version and web server, matched to the versions each project currently supports
Fixed-scope agreement with deliverables and timelines confirmed in writing before any work starts

How we build

Security testing of the public site, authenticated areas and integrations, covering the module or plugin layer where most exposure sits
Configuration hardening for file permissions, update automation, admin access and outbound services, documented per environment
Identity integration for editors and administrators where your directory requires it, such as SAML or OpenID Connect for Drupal
Upgrade rehearsal in a staging copy so each security release is tested against your own modules before production

How we hand over

Runbook covering the patch cadence, who approves updates and how a critical advisory is handled on a weekend
Evidence pack with test results, configuration baselines and change records that your auditors or assessors can review
Backup and restore procedures tested against your database and file storage, with recovery steps written for your team
Training for the people who will maintain the site, so patching does not depend on one contractor

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainer scope is agreed in writing, including which modules or plugins are watched and how often testing repeats
Retesting after each major core upgrade, such as the move to a new Drupal major version, is scoped as its own deliverable
Ask for the retainer terms, response expectations and exclusions in your quote before committing

Drupal vs WordPress security