Drupal security updates and patch cadence

Drupal has one of the most disciplined security processes of any open-source project. Advisories are coordinated, published on a predictable schedule, and rated consistently. That predictability is an advantage only if your team is set up to use it. The sites that get compromised are rarely hit by a surprise. They are hit by a vulnerability that was announced, rated, and patched upstream weeks earlier, while the site waited.

How Drupal security releases work

• The Drupal Security Team coordinates fixes privately with maintainers, then publishes a security advisory (SA) with the fixed release at the same time.
• Releases follow a regular weekly window, so teams know when to look.
• For the most serious core issues, a public service announcement (PSA) goes out days ahead, stating the date and the severity without the details. That is your signal to book a patch window before anyone knows what the flaw is.
• Coverage applies to supported versions. Core branches and contributed projects that have reached end of life receive no advisories at all, which is one reason to stay current.

Reading the risk levels

Each advisory carries a risk rating calculated from how easy the issue is to exploit, what an attacker needs, and what they can do. The levels, from most to least serious, are highly critical, critical, moderately critical, less critical, and not critical.

The rating is a starting point, not the whole story. Two questions refine it for your site:

1. Do we run the affected code? A contributed-module advisory only matters if the module is installed, and sometimes only if a specific feature of it is enabled.
2. Can an anonymous visitor reach it? A flaw that needs an administrator account is less urgent on a site with a handful of trusted admins than one exploitable by anyone.

Knowing what you run

You cannot assess advisories quickly without an accurate inventory. On a Composer-managed site, composer.lock is that inventory. Two commands help:

composer audit
drush pm:security

composer audit lists installed packages with known advisories. drush pm:security checks Drupal core and contributed projects against Drupal's own security data. Running both on a schedule, and in the deployment pipeline, catches anything missed.

A patch routine

1. Watch security announcements and PSAs continuously, not monthly.
2. Assess each advisory against your inventory the day it is published: affected or not, and how urgently.
3. Update on a branch with Composer, run database updates, and export configuration if it changed.
4. Verify on stage: the affected feature, login, forms, search, and anything the module touches.
5. Deploy through the pipeline with drush deploy and a backup point taken first.
6. Confirm the new version is live and the site is healthy.

Highly critical and critical issues on code you run go through this routine immediately, through an expedited change path, rather than waiting for the next monthly maintenance window. Lower-rated issues can join the regular cycle.

When there is no patch yet

Occasionally a module is marked unsupported, or a fix is not available for your version. Options in that situation are to disable the affected feature, block the vulnerable path at the web application firewall, replace the module, or apply a community patch after review. Each is a short-term measure while a permanent fix is arranged.

Staying on supported versions

Security releases only cover supported Drupal branches and project versions. Plan major upgrades before a branch reaches end of life, with a compatibility check of every contributed and custom module well ahead of time. Running an unsupported version means every future advisory is one you cannot fix by updating.

Beyond Drupal itself

A Drupal site also depends on PHP, the web server, the database, and the operating system, plus JavaScript libraries shipped with themes and modules. Each has its own security releases. A complete patch cadence covers them all, typically through monthly maintenance plus out-of-cycle fixes for critical issues.

How eWay handles Drupal security

eWay monitors Drupal security advisories and PSAs continuously, assesses each one against your site's inventory on publication, and books patch windows as soon as a highly critical release is announced. Critical fixes follow an expedited change path rather than waiting for the monthly cycle, and every patch is validated in a non-production environment first. Operating system, PHP, and database updates follow a regular maintenance cycle, vulnerability scanning runs continuously, and a WAF provides a protective layer while fixes roll out.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The advisory or PSA you are asking about, with its link
• Whether you have custom patches applied to the affected module

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: updating WordPress and Drupal safely and structuring Drupal environments. More on our Drupal page.